[gdal-dev] Reconsidering release cycle length ?
Even Rouault
even.rouault at spatialys.com
Mon Apr 27 10:20:46 PDT 2020
Hi,
I was wondering if we should not reconsider the length of our release cycles.
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)
I've also heard voices wishing to have more frequent bugfix releases. Every 2 months could
be reasonable.
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)
Comparison with related projects:
- PROJ: feature version every 4 months, with a bugfix release in the middle. Potential major
(breaking) version every year.
- 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...)
Of course depending on what comes to master, things could be reconsidered to let a bit more
time for maturing a feature if needed, so 6 months is more an indication than a firm delay.
This is also dependent on people doing the actual work. I'll do my share, but help always
welcome.
Thoughts ?
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/20200427/eef9372e/attachment-0001.html>
More information about the gdal-dev
mailing list