Regarding#2 - About the support of minor versions: Fair enough. We can keep the current policy for latest minor versions until we can reduce the effort it requires to release a version.
Regarding#1 - About the last major version release: About backporting security patches to the latest minor version within the previous major version, I believe that the trade-off of extra maintenance for last minor version overhead for 24 months is worth it. As a data point, based on usage of kafka-clients package in maven, majority of users are still using 2.x Kafka even after My questions to you (and the community) are: 1. If not 24 months, what is the recommendation on security support for the last minor version within the previous major/LTS version? IMO, the current 12 months is too less for users to perform a major version upgrade. 2. What needs to happen to support a longer EOL for the major/LTS version? Some ideas are having folks commit to being release manager in advance of 6 months, open up release management duty to non-committers as well (where committers can act as release shepherds), increase the number of active committers in proportion to the amount of committer work required in the community etc. -- Divij Vaidya On Thu, Apr 13, 2023 at 11:53 PM Ismael Juma <ism...@juma.me.uk> wrote: > Clarification below. > > I did not understand your point about maintenance expense to ensure > > compatibility. I am confused because, IMO, irrespective of our bug fix > > support duration for minor versions, we should ensure that all prior > minor > > versions are compatible. Hence, increasing the support duration to 24 > > months will not add more expense than today to ensure compatibility. > > > > No, I am not saying that. I am saying that there is no reason not to > upgrade from one minor release to another since we provide full > compatibility between minor releases. The expensive part is that we release > 3 times a year, so you have to support 6 releases at any given point in > time. More importantly, you have to validate all these releases, handle any > additional bugs and so on. When it comes to the CVE stuff, you also have to > deal with cases where a project you depend on forces an upgrade to a > release with compatibility impact and so on. Having seen this first hand, > it's a significant amount of work. > > Ismael >
