All, What does it mean to be OpenSource? For me the community is developers/maintainers who work on Cassandra, operators who run Cassandra, and developers who write applications which use Cassandra. We all need to work together to make Cassandra successful - and we need to listen to each other to make the project successful.
It's apparent that a sizable number of people haven't migrated from 3.11 to 4.x - this might be because the EOL announcement has been confusing and what EOL means is fuzzy. Does the project still fix CVEs, will there be infrastructure if someone wants to fix something, etc. So at a minimum I would expect documentation and agreement around those things. If you look at Ubuntu and Java they distinguish between LTS releases and normal releases - but they are also doing this for a long time. The quicker release cycle (a new release every year) is sort of new-ish and hasn't been digested by all operators and users. So given 3.11 only extra support for a limited time to aid the transition like OpenJDK is doing for Java 8 might be prudent - Mick raises a valid point that if we go out and say "this is the new EOL, but this time we mean it" might encourage people to hope for another extension. I have no good answer other than communicate harder and more clearly - the status quo lacks clarity which is worse. The other point Mick raises which releases to support gets to another discussion: As of today operators need to upgrade every two years and (also jump versions) aka I would need to go 3.11->4.1 right when it came out to get the full two year "support". I might feel uncomfortable going to a release which has just been released so realistically I need to update in between one and two years - give or take. This raises the question if we should dedicate some versions as LTS releases meaning they get longer support. Five years is common but that is also up for discussion. As an added benefit if there are commercial entities wanting to offer paid support they could focus on the LTS releases and bundle resources for the upstream support. This is a good discussion and I feel especially the implied CVE support needs to be more formalized. Thanks for indulging me, German ________________________________ From: Jacek Lewandowski <lewandowski.ja...@gmail.com> Sent: Thursday, April 13, 2023 11:23 PM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL 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<mailto: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.
