<div dir="ltr">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.<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>You can see some of my biases in this talk by Titus... "C++ as a "Live at Head" Language" <a href="https://youtu.be/tISy7EJQPzI">https://youtu.be/tISy7EJQPzI</a></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 10, 2017 at 7:51 AM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Nov 10, 2017 at 8:48 AM, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br>
<br>
> To me this is just churn, and makes people have to update all sorts of<br>
> things for no reason. I prefer leaving the project name as is, and just<br>
> using version numbers as apropriate. I see nothing wrong with PROJ.4<br>
> version 5.0.<br>
<br>
</span>I'm interested to hear other opinions, although I suppose version<br>
numbering is the ultimate bike shedding exercise. I agree it's going<br>
to cause churn, and that churn was my primary objection to<br>
incrementing the name in the first place. That said, it seems<br>
dissonant to me to call it PROJ.4 v 5.0.0.<br>
<br>
Here are some facts about the next upcoming PROJ.5 release:<br>
<br>
* A number of serious and sometimes silly warnings, overflows, and<br>
bugs were found and fixed due to participation in the Google OSS Fuzz<br>
project <a href="https://github.com/google/oss-fuzz" rel="noreferrer" target="_blank">https://github.com/google/oss-<wbr>fuzz</a><br>
* Generalized geodetic transforms<br>
* A "modern" API is now available (3rd attempt to create one over the<br>
history of the project, I think?) to take advantage of the transforms,<br>
streamline usage, and provide more safety<br>
* Significant command line tool improvements<br>
<br>
Kristian and Thomas' recent efforts are the first sustained<br>
development activity that PROJ has had since Frank spent a bunch of<br>
time in the codebase in the early 2000s. We should expect there will<br>
be a few bumps.<br>
<div class="HOEnZb"><div class="h5"><br>
Howard<br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>