> > There is a high cost to maintain a lot of old releases, backport bug > > fixes, and security patches. In general, we actively support the last > > 3 minor releases while continuing to develop the next release. E.g., > > 2.8, 2.9, and 2.10, while 2.11 is under development. > > Is 2.7 EOL? If so then we need to announce it explicitly.
Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be included. The point though still remains in that there's nowhere in the website where a user could check until when the 2.7 release is going to be supported. > > We need to ensure that we have a date set in stone to deliver the > > release to users. > > I would like the new plan to address the delays in cherry picking changes. > These must never wait until a release is being made. We must keep these up to > date. If someone marks a PR for an older release then they are volunteering > to do the cherry pick within a few days. We need to be prepared for a 0-day > security release. I agree that this is a problem, though I'd prefer to keep it in a separate proposal, specifically targeted at the process for patch releases, to avoid putting too many things into a single discussion. > > The major version bump will not carry any special meaning in terms of > > "big features" included in the release or breaking API changes. > > Instead, it would simply signal the type of the release. > > From our existing release what is LTS? Good point, as we discussed earlier, 2.10 should be marked as LTS for being the last Java 8 release. I'll update the text to reflect this. > Does this mean that you are proposing the current Master as release/3.0 or > will it remain 2.11? I was actually not thinking of changing the denomination of 2.11. On one hand, it could make sense for being the first Java 17 release, but on the other, we'd be releasing 2 LTSs super close between each other and we'd have to support 1 release more for the time being. I'd like to hear more opinions here :) > > The support model will be: > > > > * LTS > > * Released every 18 months > > * Support for 24 months > > * Security patches for 36 months > > * Feature releases > > * Released every 3 months > > * Support for 6 months > > * Security patches for 6 months > > Are those times since the initial release? It would be helpful to have a swim > lane diagram. Yes, from the initial release (eg: 3.0.0) and yes we would have a clear diagram on the website. > > This can be translated into: > > * We support the last 2 LTS releases and the last 2 feature releases > > * Security patches are provided for the past 3 LTS releases and 2 > > feature releases > > Please note that in the event of a security release that PMC members will > generally need to do these in secret. No changes about that. This is only to set the user expectation for how long they can expect the security patches. It doesn't change a comma on the PMC process of discussing such releases, nor it would prevent doing additional security releases outside of the "guaranteed" window. > What is the plan for bug fix / security releases on say 3.0? Since 3.0 would be LTS, based on the above-proposed table: 2y for bug fixes - 3y for security patches
