<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
No objections, as it were. This will be the release schedule for the next couple of years.
<div class="">I’ve added the releases up til 8.0.0 as milestones on GitHub: </div>
<div class=""><br class="">
</div>
<div class=""><a href="https://github.com/OSGeo/PROJ/milestones?direction=asc&sort=due_date&state=open" class="">https://github.com/OSGeo/PROJ/milestones?direction=asc&sort=due_date&state=open</a>
<div class=""><br class="">
</div>
<div class="">I’m sure circumstances will warrant changes to the schedule. I expect that a bugfix</div>
<div class="">release migt be changed to a new-feature release at some point. I intend to stick with</div>
<div class="">the bimonthly schedule though.</div>
<div class=""><br class="">
</div>
<div class="">I have only put in one milestone for the 6.x branch but there may be more than one</div>
<div class="">release of that branch if it isn’t too complicated to backport fixes. Basically I don’t want</div>
<div class="">promise anything but we’ll try to keep it going as long as possible.</div>
<div class=""><br class="">
</div>
<div class="">/Kristian<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 26 Feb 2020, at 15:55, Kristian Evers <<a href="mailto:kreve@sdfe.dk" class="">kreve@sdfe.dk</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">All,<br class="">
<br class="">
With the release of PROJ 7 we are out of scheduled releases. I want to put in place a new schedule so that downstream projects can plan their own releases accordingly. Lately we've seen a few interconnected bugs in QGIS where an unfortunate combination of new
PROJ and GDAL was used in a QGIS version build for an older combination of PROJ/GDAL. This was no-ones fault but could have been avoided with a bit of planning across the projects. This is a step in that direction.<br class="">
<br class="">
I propose we continue the release frequency that was used between 6.0.0 and 7.0.0. That is, bimonthly releases alternating between bug fix releases (patch) and new-feature releases (minor version number) culminating in a major release version in March. Of course
with the option of promoting a bug fix release to a minor version release if that is deemed preferable. Ad hoc releases like 6.3.1 will also be a possibility but only for bug fixes and shouldn't mess up the overall schedule.<br class="">
<br class="">
I've looked into other OSGeo projects release schedules but unfortunately it seems to be only QGIS that has a long-term plan for their releases [0]. I haven't been able to find the same for projects like GDAL, PostGIS, Mapserver, etc.
<br class="">
<br class="">
Below I have made a list of up-coming my proposed PROJ release and intertwined them with planned (or presumed [1]) QGIS releases in the future:<br class="">
<br class="">
PROJ 6.3.1: 2020-02-13<br class="">
QGIS 3.12.0: 2020-02-21<br class="">
PROJ 7.0.0: 2020-03-01<br class="">
PROJ 7.0.1: 2020-05-01<br class="">
QGIS 3.14.0: 2020-06-19<br class="">
PROJ 7.1.0: 2020-07-01<br class="">
PROJ 7.1.1: 2020-09-01<br class="">
QGIS 3.16.0: 2020-10-23 (LTR)<br class="">
PROJ 7.2.0: 2020-11-01<br class="">
PROJ 7.2.1: 2021-01-01<br class="">
QGIS 3.18.0: 2021-02-xx<br class="">
PROJ 8.0.0: 2021-03-01<br class="">
PROJ 8.0.1: 2021-05-01<br class="">
QGIS 3.20.0: 2021-06-xx<br class="">
PROJ 8.1.0: 2021-07-01<br class="">
PROJ 8.1.1: 2021-09-01<br class="">
QGIS 3.22.0: 2021-10-xx (LTR)<br class="">
PROJ 8.2.0: 2021-11-01<br class="">
PROJ 8.2.1: 2022-01-01<br class="">
PROJ 8.3.0: 2022-03-01<br class="">
<br class="">
As it can be seen from the list the two schedules generally fit well together with QGIS long-term releases being issued roughly two months after PROJ as had the fix bug fix release of a new minor version branch. Or put in another way, we've had four releases
to weed out bugs in a new major version release, which should provide a solid release for QGIS to build on.<br class="">
<br class="">
I tried to look up the release schedules of various Linux distributions to see how those would fit since in the end the packaging systems will be the limiting factor for the whole OSGeo stack. I found it hard to come to any form of conclusion that could guide
our release schedule though. I assume most distributions will be a major version branch behind when it comes to PROJ for the next year or two, until we have weeded out proj_api.h for good.<br class="">
<br class="">
It would be great to get feedback on the release schedule from PROJ developers, developers of other packages depending on PROJ and the packagers as well.<br class="">
<br class="">
/Kristian<br class="">
<br class="">
[0] <a href="https://www.qgis.org/en/site/getinvolved/development/roadmap.html" class="">
https://www.qgis.org/en/site/getinvolved/development/roadmap.html</a><br class="">
[1] QGIS release dates ending in xx are presumed releases that doesn't figure in the road map<br class="">
<br class="">
_______________________________________________<br class="">
PROJ mailing list<br class="">
<a href="mailto:PROJ@lists.osgeo.org" class="">PROJ@lists.osgeo.org</a><br class="">
https://lists.osgeo.org/mailman/listinfo/proj<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>