I'm not sure I fully understand the LTS release and feature release. > The LTS releases will be identified by being a `.0` version. For example: > * `3.0` -> LTS > * `3.1` -> regular release > * `3.2` -> regular release > * `4.0` -> LTS
In this example, we can only introduce new features in 3.1 and 3.2, and 3.1.x and 3.2.x should be the patch release based on the feature release? We can have one patch release for a month. 3.0.x is the LTS release that will support at most three years. After we have 4.0 LTS release, we will still support 3.0.x TLS for at least 18 months. And 4.0 TLS will have all the new features from 3.x > 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 Does this mean we can introduce new features in 3.x even if we have 4.x? And how many patch releases for the feature releases we will support, such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x. I think 2 feature releases means 3.x and 4.x here? Thanks, Penghui On Wed, Jun 8, 2022 at 12:41 PM Michael Marshall <mmarsh...@apache.org> wrote: > 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 >
