[gdal-dev] Reconsidering release cycle length ?

[Greg Troxel]

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

> I was wondering if we should not reconsider the length of our release cycles.

Comments from the packaging peanut gallery.

> One year between feature versions is quite a lot. Perhaps 6 months would be a good 
> compromise between having enough time to mature a complex feature and faster delivery of 
> it to people not directly consuming master. A consequence of this is that our usual policy of 
> supporting the last released branch during the development cycle of the next release would 
> also go to 6 month (to avoid supporting too many branches at the same time), or perhaps 
> even 4 (see below example)

There are multiple issues, but basically "new features" doesn't bother
me and "API withdrawals/breaks" do.

  new versions have varying degrees of awkwardness:

    bug fixes, etc., with no changes in the set of installed files:
    updates are very very easy

    new files: tiny amount of work, but no angst

    shlib major bumps or any other ABI break: more work as all depending
    packages need to be rebuilt, but not terrible.  However, shlib major
    bumps indicate API withdrawals (or poor library versioning
    practices).

    API withdrawals/breaks, i.e. things that cause things that depend on
    gdal not to build: really bad, and would delay adoption

  new versions impose work variously as above, and whether you call them
  feature or bugfixes doesn't matter too much to me.  I see the first as
  bugfix, the second as feature, and the third and fourth as breaking
  changes, with the third being awkward and the fourth serious.

  bundling shlib bumps reduces total packaging effort (but you should
  avoid shlib bumps anyway)

  Each API withdrawal basically causes the same amount of pain, and
  bundling doesn't really reduce total pain, except that if some
  depending package fixes two things at once, the savings is them
  actually having a release only once.  For withdrawals to be ok means
  that that *every* depending package has to have a *formal release*
  that builds against the new API before the new gdal release that
  withdraws the API.  (Not what you asked, but this is the big deal and
  everything else is just details.)

> I've also heard voices wishing to have more frequent bugfix releases. Every 2 months could 
> be reasonable.

>From a packaging point of view, a release with only bugfixes (whose
"NEWS" clearly states this) is very easy and welcome.   Also from a
packaging point of view, if you had a bugfix release every 2 weeks and I
got to some of them and not others, that would be fine too.

> So a likely schedule could be:
>
> T0 (now)				GDAL 3.1.0
> T0 + 2 months			GDAL 3.1.1
> T0 + 4 months			GDAL 3.1.2
> T0 + 6 months			GDAL 3.2.0 (optionaly, a final 3.1.3)

OK with me.

You didn't discuss the LTS elephant in the room.  Some systems like to
freeze a version for 5 years, and want bugfixes, while their users
simultaneously want to build new versions of other software, but only
depending on the old included versions.  My view is that since those
users aren't paying gdal to maintain LTS branches, you shouldn't worry
about this at all.

> Comparison with related projects:
> - PROJ: feature version every 4 months, with a bugfix release in the middle. Potential major 
> (breaking) version every year.

Breaking changes every year is faster than depending projects have
coped.  This really should be avoided; I don't think proj should be held
up as a good plan here.

> - QGIS: feature version every 4 months, with monthly bugfix releases (way more complicated 
> than that with several versions supported in parallel, but was to make it simple...)

That's fine, but the real issue is "other packages that need X to build
- does the most recent formal release still just build".  With qgis, not
clear how much depends on it, and I haven't heard screams about API breaks.