If there’s lack of clarity around EOL policy and dates, we should absolutely make this clear.
Most releases of the project have been “LTS” in that the release cadence since 2018 has not been rapid but focused on minor enhancements on long-lived branches like 3.0, 3.11, and 4.0.x. But I’d distinguish between the idea of “LTS” and stability, as stability is continually improving and contributors are bringing a stronger focus to low-effort upgrades and minimizing deprecations.
Cassandra 3.11 was released six years ago, with major progress in quality, stability, and features since that time. Contributors have brought more attention to a smooth upgrade experience than I’ve seen in nearly any OSS database.
If there are vendors who offer Apache Cassandra as a service or provide paid support who wish to offer extended security updates for EOL’d releases, this seems like a fine area to step in - e.g., via an affirmative commitment of resources to identify vulnerabilities in legacy releases and provide targeted patches to address them.
It feels like another thing to ask the project (who are a community of contributors) to provide post-EOL support for releases with a published end-of-support date. Who will do that, and who will honor that commitment? The project does not have the ability to demand specific contributions from its contributors, and most contributors are focused on advancing the project forward.
It seems likely that such contributions would be welcome - e.g., dependency bumps, surgical fixes, or default config changes needed to address a vulnerability found in an older release — especially if a future “log4j”-like discovery were to occur.
But it seems difficult for the project to bind itself to this as a matter of policy, and a great area for a vendor who is interested in this being warranted to commit the resources needed for it to be possible.
— Scott On Apr 14, 2023, at 9:14 AM, German Eichberger via dev <dev@cassandra.apache.org> wrote:
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
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.
|
