EOL Policy?

[hobu]

Looking at the downloads listing, there is a link to everything back to 4.9.1, but branches are not maintained that far back. I think we should communicate that fact on downloads page to label which releases are dead or EOL. A simple mark of (EOL) after that release name/number should be sufficient.

As for what the EOL policy is in regards to what's actually no longer supported, I don't have a strong opinion. At this point, with 9.0.0 coming out soon, I would think anything in the 6's is still acknowledged as 'modern' or 'current', but there's no pushing of fixes that far back.

The point of this is so other projects like PostGIS and GDAL that depend on PROJ can provide a minimum version floor.

[robe2]

I concur. At the very least some label of EOL would be good. I think such a warning will also discourage packagers from packaging old versions of PROJ, because no one wants to be packaging an EOL product.

On the PostGIS side, we do have an EOL page -

Which gives some idea of our versioning policy. Ours is pretty loose. But we also make it clear no security patches will be provided for EOL products. That will give packagers and DbaaS extra push on their bosses to stop using old versions.

https://postgis.net/eol_policy/

[rouault]

As soon as 9.0.0 will be out, given our current practice of doing bug fixes only on the current release, all previous versions will be EOL by definition. So I guess the "Past Releases" paragraph is a synonym for EOL.

[kbevers]

So I guess the "Past Releases" paragraph is a synonym for EOL.

I agree with this. At this point I consider anything but the latest release end-of-lifed. Things have been moving quite rapidly over the last 3-4 years and I think 9.x will have a significant longer shelf-life than 5.x, 6.x, 7.x and 8.x have had. With that in mind, when 10.x eventually comes out it could make sense to keep releasing fixes to 9.x for a while. That's assuming 10.x brings changes in the same magnitude as the 5 to 6 transition. I don't think it makes sense to plan ahead on this right now and clearly stating that anything but the current release is unsupported is likely the best course of action.

[jmckenna]

"EOL" also means "not maintained" and then of course, which versions will get security patches. As you all know, this is handled/defined by adding a SECURITY.md file into your base repository (example see https://github.com/MapServer/MapServer/blob/main/SECURITY.md). GitHub makes it easy to add into the repository, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository

It might be good for PROJ to define there how to report security issues, and which versions will be supported for security patches. (I remember a grid file was reported as corrupt or insecure back in 2009-ish, that's how old I am here in PROJ ha)

[hobu]

I think 9.x will have a significant longer shelf-life than 5.x, 6.x, 7.x and 8.x have had.

Does this mean that the release pace will slow, and the time window between major releases will increase? I think it would be convenient to align PROJ's release stance with GDAL's in terms of major and minor releases and the expectations of backports to any previous maintenance branches. They are kindred in many ways, PROJ releases often project changes downstream to projects like GDAL, and how much more major feature development is actually left in PROJ to achieve?

[kbevers]

Does this mean that the release pace will slow, and the time window between major releases will increase?

At least the latter. We've taken care of all the breaking changes that were in the pipeline so I expect the 9.x branch to live on for some years. I think downstream projects will appreciate some stability from us.

I have been thinking about limiting the number of minor releases to two similar to GDAL. I think that would be sufficient. Aligning the two projects release schedules makes sense and if I'm not mistaken they are already somewhat aligned. A GDAL release quite often follows a PROJ release.

I'm not sure about maintenance releases of previous branches (e.g for 8.x when 9.x is out). It would be a lovely thing to have and assuming we have a less dynamic code base from now it might even be feasible. I don't think I'm the right person to handle that though. I'm already struggling to find the time to keep up with the current release schedule. Should someone be willing to take over I'd be happy to let it go.

[hobu]

I'm already struggling to find the time to keep up with the current release schedule. Should someone be willing to take over I'd be happy to let it go.

You are doing an excellent job, and if the pace is the challenge, it seems there is sentiment to slow that down now that major development activities related to all of the geodetic work are for the most part done and in place.

[kbevers]

and if the pace is the challenge, it seems there is sentiment to slow that down now that major development activities related to all of the geodetic work are for the most part done and in place.

Absolutely. I should easily be able to keep up with let's say quarterly releases. I think that is sufficiently frequent as well. Maintaining several branches of releases will be challenging for me though. That could possibly be dealt with by automating more of the release process. Unfortunately I haven't got the skillset or the time to do it myself. It's probably worth discussing further after the 9.0.0 release.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.