You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by German Eichberger via dev <de...@cassandra.apache.org> on 2023/04/13 17:59:06 UTC
(CVE only) support for 3,11 beyond published EOL
All,
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.
Given that there are still a sizable number of users on 3.11 in [2] we talked about a CVE only support for some time. When we discussed that internally at Azure we entertained supporting until Java 8 is EOL but with that now being 12/31/2030 [4] we quickly gave up on that and are now thinking a shorter time. 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.
Thanks,
German
[1] https://the-asf.slack.com/archives/CJZLTM05A/p1678451091766109
[2] https://the-asf.slack.com/archives/CK23JSY2K/p1680125394038599
[3] https://cassandra.apache.org/_/download.html
[4] https://endoflife.date/java
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by Mick Semb Wever <mc...@apache.org>.
On Sat, 15 Apr 2023 at 03:17, C. Scott Andreas <sc...@paradoxica.net> wrote:
> If there’s lack of clarity around EOL policy and dates, we should
> absolutely make this clear.
>
Fix is here:
https://github.com/thelastpickle/cassandra-website/tree/mck/update-5-0_dates_download_page
w/ html generated here:
https://raw.githack.com/thelastpickle/cassandra-website/mck/update-5-0_dates_download_page_generated/content/_/download.html
I'll merge this tomorrow if there's no further input.
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by Henrik Ingo <he...@datastax.com>.
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 <le...@gmail.com>
> *Sent:* Thursday, April 13, 2023 11:23 PM
> *To:* dev@cassandra.apache.org <de...@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 <mc...@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/>
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by "C. Scott Andreas" <sc...@paradoxica.net>.
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
> <de...@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 <le...@gmail.com>
> **Sent:** Thursday, April 13, 2023 11:23 PM
> **To:** dev@cassandra.apache.org <de...@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
> <[mck@apache.org](mailto:mck@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.
>>
>>
>
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by German Eichberger via dev <de...@cassandra.apache.org>.
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 <le...@gmail.com>
Sent: Thursday, April 13, 2023 11:23 PM
To: dev@cassandra.apache.org <de...@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 <mc...@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.
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by Jacek Lewandowski <le...@gmail.com>.
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 <mc...@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.
>
>
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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.
Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
Posted by German Eichberger via dev <de...@cassandra.apache.org>.
Josh,
________________________________
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"?
Yes, this would be great. Right now users are confused what EOL means and what they can expect.
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.
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.
Re: (CVE only) support for 3,11 beyond published EOL
Posted by Josh McKenzie <jm...@apache.org>.
> 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.
>
Re: (CVE only) support for 3,11 beyond published EOL
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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.