Thanks for putting together this PIP to continue this discussion, Matteo. This is an important one.
I'll need time to think over your points before I respond, but I want to address two of them right away. > 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 actually do have this documented on the website. I added this page in February: https://pulsar.apache.org/docs/next/security-policy-and-supported-versions#supported-versions. > 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 agree with this reasoning. If 2.10 is LTS, and I think it should be, 2.11 shouldn't be LTS. Thanks, Michael On Tue, Jun 7, 2022 at 6:39 PM Matteo Merli <matteo.me...@gmail.com> wrote: > > > > 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
