[Proj] Time for a new release?

[Kurt Schwehr]

When I'm following point releases (Mac OSX fink), I prefer more frequent
releases and smaller deltas.  That reduces the risks of breakages and gets
fixes in sooner.  With more time between releases (and packager updates),
we tend to get wedged for long periods of time.  I prefer not to see crazy
version jump.  I prefer to see traditional API change based version bumps,
but that's really hard to do as what is a break change can be surprising.

For most of my work, I've given up on point releases completely and am
going with patch by patch.  I do have to combine a few patches sometimes to
get to the next stable point, but it's super easy to do.  That means I can
usually isolate a behavior change down to the smallest bit of code and work
on handling that with my users.  And if there is a patch a user can't cope
with, I can (usually) hold just that change back for a while and keep
applying other patches for a while.

I'm still working to catch up to head, but the switch has already been
paying off massively.   I have a bunch of bugs that I haven't reported yet
as I'm sure a large fraction of them were caught by OSS Fuzz and already
fixed in Proj.4.

I've done the same for GEOS and GDAL.  Working patch by greatly reduced the
stress involved in updating.  It's a lot easier to catch and manage
behavior changes that impact my users.

You can see some of my biases in this talk by Titus... "C++ as a "Live at
Head" Language" https://youtu.be/tISy7EJQPzI



On Fri, Nov 10, 2017 at 7:51 AM, Howard Butler <howard at hobu.co> wrote:

> On Fri, Nov 10, 2017 at 8:48 AM, Greg Troxel <gdt at lexort.com> wrote:
>
> > To me this is just churn, and makes people have to update all sorts of
> > things for no reason.  I prefer leaving the project name as is, and just
> > using  version numbers as apropriate.   I see nothing wrong with PROJ.4
> > version 5.0.
>
> I'm interested to hear other opinions, although I suppose version
> numbering is the ultimate bike shedding exercise. I agree it's going
> to cause churn, and that churn was my primary objection to
> incrementing the name in the first place. That said, it seems
> dissonant to me to call it PROJ.4 v 5.0.0.
>
> Here are some facts about the next upcoming PROJ.5 release:
>
> * A number of serious and sometimes silly warnings, overflows, and
> bugs were found and fixed due to participation in the Google OSS Fuzz
> project https://github.com/google/oss-fuzz
> * Generalized geodetic transforms
> * A "modern" API is now available (3rd attempt to create one over the
> history of the project, I think?) to take advantage of the transforms,
> streamline usage, and provide more safety
> * Significant command line tool improvements
>
> Kristian and Thomas' recent efforts are the first sustained
> development activity that PROJ has had since Frank spent a bunch of
> time in the codebase in the early 2000s. We should expect there will
> be a few bumps.
>
> Howard
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20171110/5e26dbf6/attachment.htm