[gdal-dev] Reconsidering release cycle length ?

[Even Rouault]

Answering to several people in a row:

@Eli

> If people were not compelled to track master, then this
> engagement with the project might be reduced or pushed to releases
> with a less interactive feedback (i.e. they won't be testing patches
> or recent commits).  From my own personal experience, GDAL has been
> the only project worth tracking master and engaging in this way.
> Other projects, I wait for the release and take a binary and am less
> in a position to provide testing or meaningful feedback.  Tracking
> master and engaging with GDAL has been a rewarding experience for me
> over the years.

I'm not sure why having shorter cycles would increase or decrease potential candidates to 
tracking master. It seems to me to be more related to their own interest in the project, which 
should be somewhat independent from the length of the cycle. People highly interested in 
the project should still track it as closely as they are used to if they want the same level of 
quality, and people more remotely interested will probably just wait for their binary 
distribution channel to bring releases to them.

Having shorter feature cycles can also help reduce developer frustration: when you start 
getting bug reports for a feature you added > 1 year ago (because most users 
understandably use a packaged version), you may have already forgotten lots of details. 
When I update the NEWS file before release, I'm sometimes surprised to have to qualify as 
new something that looks to me as having been developed years ago :-)

@Greg

>  API withdrawals/breaks

We try to avoid those when possible. But we have more frequently changes that have some 
backward compatibility challenges (generally a few per feature version), not always detected 
at build time. That can be things like:
- a new value added to a C enumeration in the API. Requiring user code to deal with this new 
possibility
- an option disappearing / being renamed for more generality
- other changes of runtime behaviour. Like in this cycle, the OGR SQL "LIKE" operator 
becoming case insensitive.

Those are documented in the MIGRATION_GUIDE.TXT file.
Adressing those changes for code using GDAL is almost equally important as making sure 
that the code still builds.

> You didn't discuss the LTS elephant in the room.

Speaking from my experience, candidates like proprietary shops that could provide $$ to 
make that happen generally resync their GDAL build with a release or some state of master 
from time to time. And perhaps potentially pick a particular bugfix of interest occasionaly.

Regarding LTS-labelled Linux distros, for the few on I've looked at, they don't seem to update 
to the latest patch release we provide for a given feature version, and are stuck to the one 
that existed at the time the .0 of the distro was frozen. Probably lack of man power, or too 
strict update policies that restrict maintainers to do cherry-picking (quite risky IMHO when 
done not with someone intimate with the code base) rather than rolling a new patch release.

For a project vetted LTS, beyond having acceptance within GDAL devs and potential funding 
for it, one difficulty would be to choose which version to LTS. Or perhaps do like QGIS does, 
just say "eh, every one out of N feature versions is the LTS.". People also tend to disagree 
what a LTS is: for some it is something mostly frozen with minimal changes (security ones), 
for others something that can receive any non-breaking change (including things that could 
qualify as features), and a lot of in-between situations (for QGIS we discussed recently the 
possibility to have several phases: an initial one where changes are accepted liberaly, and a 
last one where only "critical" bug fixes can land)

But, anyway, I've not heard yet converging demands for such a thing for GDAL.

> [Regarding PROJ] Breaking changes every year is faster than depending projects have 
coped.

Yes, was annoying but needed to keep PROJ relevant for current and future geodetic 
challenges, after years of stagnation. Our geospatial projects are lively objects that cannot 
be compared to Unix base tools that are almost set in stone forever :-)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200428/09677863/attachment-0001.html>