To me, as this is an open source project, we, the community, do not have to do anything, we can, but we are not obliged to, and we usually do that because we want to :-)
To me, EOL means that we move focus to newer releases. Not that we are forbidden to do anything in the older ones. One formal point though is the machinery - as long as we have the machinery to test and release, that's all we need. However, in face of coming changes in testing, I suppose some extra effort will have to be done to support older versions. Finding people who want to help out with that could be a kind of validation whether that effort is justified. btw. We have recently agreed to keep support for M sstables format (3.0 - 3.11). thanks, - - -- --- ----- -------- ------------- Jacek Lewandowski czw., 13 kwi 2023 o 21:59 Mick Semb Wever <m...@apache.org> napisał(a): > Yes, this would be great. Right now users are confused what EOL means and >> what they can expect. >> >> > > I think the project would need to land on an agreed position. I tried to > find any reference to my earlier statement around CVEs on the latest > unmaintained branch but could not find it (I'm sure it was mentioned > somewhere :( > > How many past branches? All CVEs? What if CVEs are in dependencies? > And is this a slippery slope, will such a formalised and documented > commitment lead to more users on EOL versions? (see below) > How do other committers feel about this? > > > I am also asking specifically for 3.11 since this release has been around >> so long that it might warrant longer support than what we would offer for >> 4.0. >> >> > > This logic can also be the other way around :-) > > We should be sending a clear signal that OSS users are expected to perform > a major upgrade every ~two years. Vendors can, and are welcome to solve > this, but the project itself does not support any user's production system, > it only maintains code branches and performs releases off them, with our > focus on quality solely on those maintained branches. > >
