[gdal-dev] Reconsidering release cycle length ?

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> 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.

For Eli's comment, I'm not sure the release interval matters much
either.

There is an important aspect about people that just want to be users and
thus *should* be using binary releases, but feel pressed into running
git master for various reasons.  I have not really seen this with gdal,
but some projects end up giving advice like "the release is old; you
should run git master".  So I'd say "people that are simply users of
gdal feeling that they should run master is a clue that a feature
release is overdue", without suggesting that this is actually the case.
But certainly I have seen that on some projects.

> 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.

I'm not following if these are only in your 'breaking changes releases'
vs 'feature releases'.  But I have not epxerienced pain about these
changes, and with N formats, minor changes that don't cause too much
trouble are minor.

> 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.

I'm not a fan of LTS, and I'm really not a fan of the concept of wanting
to run LTS while also wanting to build new software at the same time.  I
agree with you that gdal shouldn't worry about this at all.