Even Rouault <even.roua...@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
