> We already have an understanding and precedence in place that CVEs on > the previous unmaintained branch are addressed and released. Correct me if I'm wrong German, but the question I got from your email was effectively "If we consider formalizing our commitment to fixing CVE's on older branches that are out of formal bugfix support as a community, what are the benefits and costs to doing that"?
On Thu, Apr 13, 2023, at 2:47 PM, Mick Semb Wever wrote: > > > > There have been several discussions on slack [1], [2] to support 3.11 > > beyond the date stated on the web [3] which is May-July 23 and given it's > > April that's an unlikely date. > > > > > Strictly speaking it is maintained until the 5.0 GA release. We should > update the downloads page accordingly. > > > > > > So we will support anyway but I would like to start a broader discussion if > > we, the community, are interested in at a minimum CVE only support, maybe > > bug fixes as well, after 5.0 is released for 3.11 and if so for how long - > > something like a Cassandra LTS policy. > > > > > > The community's resources are limited, and the statement is intended > to avoid tying up resources and to avoid letting users down. This is > open source and "to upgrade" is often our easy and pragmatic answer. > > It is not a statement that fixes to older branches will be rejected. A > (two) committers can still push to older branches, and a release can > still happen if you find someone to do it (and three PMCs to +1 it). > This is why the 2.2 branch is still present on ci-cassandra.a.o. If > vendors want to provide support for versions longer and can make the > commitment to upstream those efforts (whether that's bug-fixes and > releases, or only bug-fixes) the machinery is in place to accept it. > > We already have an understanding and precedence in place that CVEs on > the previous unmaintained branch are addressed and released. >
