[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