I concur with Scott here. LTS and extended support is precisely what vendors are in a good position to offer. And in practice such support is always available, also today, since a vendor will always agree to support any old version as long as a price is agreed for the custom arrangement.
If I think about for example how LTS evolved for the Linux kernel, it was originally completely the domain of vendors to offer support. Linus and team were completely focus on the next release, where essentially every release after 2.6.0 was a major release. (Everything else was a release candidate.) But just like the development of mainline Linux is most efficient when everyone pools their efforts, a group of people eventually have started to work on -stable maintenance releases and ultimately once per year also a 6 year long LTS release. Vendors realize it makes sense for them to work together on a single LTS branch (per year) rather than each vendor shuffling patches in their own forks. But even then the -stable and LTS work is done by dedicated teams who specifically work on that maintenance work. It's a feature just like working on a driver or scheduler. So similarly for Cassandra, if a credibly sized team of developers would step forward to say that they have been assigned by their employer to provide LTS support for (for example) 3.11. then the project should consider that offer basically just like a CEP or other major piece of work. *** On the other hand, you can of course also make the argument that LTS support is something the project absolutely should focus on as a priority, and particularly to offer it for free, without users having to pay any vendor. (e.g. Ubuntu LTS works like this) The rationale for this argument is then that the LTS support is a valuable feature for end users and it would benefit Cassandra adoption to offer it directly from the project itself and we should therefore divert resources away from e.g. transactions to work on LTS. I currently don't believe LTS is more important than the many features we are working on. But it certainly could be the case, so it's definitely fair game as a conversation to have. henrik On Sat, Apr 15, 2023 at 4:17 AM C. Scott Andreas <sc...@paradoxica.net> wrote: > 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 > > > 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. > > -- Henrik Ingo c. +358 40 569 7354 w. www.datastax.com <https://www.facebook.com/datastax> <https://twitter.com/datastax> <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
