Pushing CASSANDRA-16262 out of 4.0-rc

[Caleb Rackliffe]

Hey everyone,

I wanted to have a quick conversation about CASSANDRA-16262
. As I mentioned in
the Jira

...

*"I was chatting w/ Andres de la Peña
 the
other day, and it feels like there's an argument for allowing 4.0 to
release without this work being complete. We've certainly come a long way
w/ CASSANDRA-15579
 already, filling in
a number of gaps that existed."*

Any strong opinions out there?

Re: [DISCUSS] Releases after 4.0

[Jeremiah D Jordan]

I think we are confusing things between minor vs patch.  Can we talk about 
branch names?

I think we can agree on the following statements?

Releases made from stable maintenance branches, 
cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit features 
being added to them and should be mostly bug fix only.

New features will be developed in trunk.

Now I think the thing under discussion here is “how often will we cut new 
maintenance branches from trunk” and also “how long will we maintain those 
branches"

I would definitely like to see the project able to release binaries from trunk 
more often then once a year.  As long as we keep our quality goals in line post 
4.0 GA I think this is possible.

> I'd like to see us have three branches: life support (critical fixes), stable 
> (fixes), and development. Minors don't fit very well into that IMO.

If we want to go with semver ideas, then minors fit perfectly well.  Server 
doesn’t meant you make patch releases for every version you have ever released, 
it is just a way of versioning the releases so people can understand what the 
upgrade semantics are for that release.  If you dropped support for some 
existing thing, you need to bump the major version, if you added something new 
you bump the minor version, if you only fixed bugs with no user visible changes 
you bump the patch version.

> I suppose in practice all this wouldn't be too different to tick-tock, just 
> with a better state of QA, a higher bar to merge and (perhaps) no fixed 
> release cadence. This realisation makes me less keen on it, for some reason.

I was thinking something along these lines might be useful as well.

I could see a process where we cut new maintenance branches every X time, ~1 
year?, 6 months?, we would fix bugs and make patch releases from those 
maintenance branches.
We would also cut releases from the development branch (trunk) more often.  The 
version number in trunk would be updated based on what had changed since the 
last release made from trunk.  If we dropped support for something since the 
last release, bump major.  If we added new features (most likely thing), bump 
minor.

So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We make 
future 4.0.1 4.0.2 4.0.3 releases from this branch.

Trunk continues development, some new features are added there.  After a few 
months we release 4.1.0 from trunk, we do not cut a cassandra-4.1 branch.  
Development continues along on trunk, some new features get in so we bump the 
version in the branch to 4.2.0.  A few months go by we release 4.2.0 from 
trunk.  Some bug fixes go into trunk with no new features, the version on the 
branch bumps to 4.2.1, we decide to make a release from trunk, and only fixes 
have gone into trunk since the last release, so we release 4.2.1 from trunk.

We continue on this way releasing 4.3.0, 4.4.0, 4.4.1 …. We decide it is time 
for a new maintenance branch to be cut.  So with the release of 4.5.0 we also 
cut the cassandra-4.5 branch.  This branch will get patch releases made from it 
4.5.1 4.5.2 4.5.3.

Trunk continues on as 4.6.0, 4.7.0, 4.8.0 …. At some point the project decides 
it wants to drop support for some deprecated feature, trunk gets bumped to 
5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0, 5.2.1 development 
on trunk continues on.  Time for a new maintenance branch with 5.3.0 so 
cassandra-5.3 gets cut...

This does kind of look like what we tried for tick/tock, but it is not the 
same.  If we wanted to name this something, I would call it something like 
"releasable trunk+periodic maintenance branching”.  This is what many projects 
that release from trunk look like.

-Jeremiah


> On Jan 28, 2021, at 10:31 AM, Benedict Elliott Smith  
> wrote:
> 
> But, as discussed, we previously agreed limit features in a minor version, as 
> per the release lifecycle (and I continue to endorse this decision)
> 
> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
> 
>> if there's no such features, or anything breaking compatibility
>> 
>> What do you envisage being delivered in such a release, besides bug
>> fixes?  Do we have the capacity as a project for releases dedicated to
>> whatever falls between those two gaps?
>> 
> 
> 
>All releases that don't break any compatibilities as our documented
>guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
>new features can be introduced without compatibility breakages (and should
>be as often as possible).
> 
>Honouring semver does not imply more releases, to the contrary it is just
>that a number of those existing releases will be minor instead of major.
>That is, it is an opportunity cost to not recognise minor releases.
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Re: [DISCUSS] Releases after 4.0

[Jonathan Ellis]

Sorry, I got my threads crossed!

On Thu, Jan 28, 2021 at 10:47 AM Jonathan Ellis  wrote:

> cqlsh isn't a new feature.
>
> On Thu, Jan 28, 2021 at 10:32 AM Benedict Elliott Smith <
> bened...@apache.org> wrote:
>
>> But, as discussed, we previously agreed limit features in a minor
>> version, as per the release lifecycle (and I continue to endorse this
>> decision)
>>
>> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
>>
>> > if there's no such features, or anything breaking compatibility
>> >
>> > What do you envisage being delivered in such a release, besides bug
>> > fixes?  Do we have the capacity as a project for releases dedicated
>> to
>> > whatever falls between those two gaps?
>> >
>>
>>
>> All releases that don't break any compatibilities as our documented
>> guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).
>> Even
>> new features can be introduced without compatibility breakages (and
>> should
>> be as often as possible).
>>
>> Honouring semver does not imply more releases, to the contrary it is
>> just
>> that a number of those existing releases will be minor instead of
>> major.
>> That is, it is an opportunity cost to not recognise minor releases.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [DISCUSS] Releases after 4.0

[Jonathan Ellis]

cqlsh isn't a new feature.

On Thu, Jan 28, 2021 at 10:32 AM Benedict Elliott Smith 
wrote:

> But, as discussed, we previously agreed limit features in a minor version,
> as per the release lifecycle (and I continue to endorse this decision)
>
> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
>
> > if there's no such features, or anything breaking compatibility
> >
> > What do you envisage being delivered in such a release, besides bug
> > fixes?  Do we have the capacity as a project for releases dedicated
> to
> > whatever falls between those two gaps?
> >
>
>
> All releases that don't break any compatibilities as our documented
> guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).
> Even
> new features can be introduced without compatibility breakages (and
> should
> be as often as possible).
>
> Honouring semver does not imply more releases, to the contrary it is
> just
> that a number of those existing releases will be minor instead of
> major.
> That is, it is an opportunity cost to not recognise minor releases.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [DISCUSS] When to stop supporting Python 2

[Sumanth Pasupuleti]

>From the "Supported upgrade path for 4.0" discussion, it seems like there
was consensus around supporting the "3.0 -> 4.0" upgrade path as well (in
addition to 3.11 -> 4.0), so we may need to add python3 support for 3.0 as
well?

Internally. we had a need to make 3.0 cqlsh python3 compatible, and I ended
up backporting trunk pylib, cqlsh, cqlsh.py for python3 support and
reverted https://issues.apache.org/jira/browse/CASSANDRA-14825 (this
backport is currently being tested). Haven't assessed the impact on dtest
environment yet. This approach was much less effort vs cherry-picking
individual changes, but involves probably equal or more testing effort. If
we decide to add python3 support for 3.0, I am happy to contribute this
once we have enough confidence from testing (but unsure if we have
the appetite for this big a change in 3.0).



On Thu, Jan 28, 2021 at 3:01 AM Benjamin Lerer 
wrote:

> Considering the issue with pip. I agree that we should remove support for
> 3.0 and ensure that python 3 is supported by 3.11.
>
> On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis  wrote:
>
> > Python 2 was EOLed over a year ago.  I think it's fine to (1) require
> > python 3 to run cqlsh and (2) remove code that supports python 2 whenever
> > it's convenient.
> >
> > Angelo has the right idea that rather than trying to finesse a
> deprecation
> > cycle into 4.0 at this late date, a better migration path can be provided
> > by backporting python3 support to 3.11.
> >
> > On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams 
> > wrote:
> >
> > > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg
> > >  wrote:
> > > > I want to emphasize here: to my way of thinking, "dropping support"
> at
> > > this
> > > > juncture is just a matter of documenting it, and maybe introducing a
> > > > warning. We don't need to *remove* support for python2. It will
> > continue
> > > to
> > > > work as-is. This would just guide us in deciding whether to work on
> > flaws
> > > > that are python2-specific, and whether new things are developed with
> > > > backwards compatibility as a forcing concern.
> > >
> > > Actually, I think we have to go a little bit further, and at least as
> > > far as packaging is concerned, remove support for python2.  Recently
> > > pip updated to 21.0 and removed python2 support, which broke any
> > > builds that built artifacts requiring pip.  We now pin pip:
> > >
> > >
> >
> https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8
> > > to get around this, but highlights that we too need to move away from
> > > anything using python2.  So while we would not modify code to *remove*
> > > python2 support, you would have to invoke python2 on the code in your
> > > own way, since the packages would depend on python3.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

But, as discussed, we previously agreed limit features in a minor version, as 
per the release lifecycle (and I continue to endorse this decision)

On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:

> if there's no such features, or anything breaking compatibility
>
> What do you envisage being delivered in such a release, besides bug
> fixes?  Do we have the capacity as a project for releases dedicated to
> whatever falls between those two gaps?
>


All releases that don't break any compatibilities as our documented
guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
new features can be introduced without compatibility breakages (and should
be as often as possible).

Honouring semver does not imply more releases, to the contrary it is just
that a number of those existing releases will be minor instead of major.
That is, it is an opportunity cost to not recognise minor releases.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

> if there's no such features, or anything breaking compatibility
>
> What do you envisage being delivered in such a release, besides bug
> fixes?  Do we have the capacity as a project for releases dedicated to
> whatever falls between those two gaps?
>


All releases that don't break any compatibilities as our documented
guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
new features can be introduced without compatibility breakages (and should
be as often as possible).

Honouring semver does not imply more releases, to the contrary it is just
that a number of those existing releases will be minor instead of major.
That is, it is an opportunity cost to not recognise minor releases.

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

> if there's no such features, or anything breaking compatibility

What do you envisage being delivered in such a release, besides bug fixes?  Do 
we have the capacity as a project for releases dedicated to whatever falls 
between those two gaps?

I'd like to see us have three branches: life support (critical fixes), stable 
(fixes), and development. Minors don't fit very well into that IMO.

> I am a bit scared of a continuous delivery approach for a database 
> due to the lack of guarantee on the APIs and protocols as you mentioned

Well, this could be resolved by marking features as unstable, then 
experimental, as we have begun doing. So that API stability is tied to features 
more tightly than releases.  I'm actually warming to this configuration, but I 
think we're all circling ideas in a similar vicinity and I suspect none of us 
are tightly wed to the specifics.

> we should allow ourselves to cut a release sooner. 

The only issue here is that we then create an extra maintenance overhead, as we 
have more releases to manage.  This is one advantage of the CD approach - we 
nominate a release much less frequently for long term support, at which point 
we rollover to a new major (presumably also only deprecating across such a 
boundary).

I suppose in practice all this wouldn't be too different to tick-tock, just 
with a better state of QA, a higher bar to merge and (perhaps) no fixed release 
cadence. This realisation makes me less keen on it, for some reason.




On 28/01/2021, 14:23, "Mick Semb Wever"  wrote:

We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>


Completely agree with this. But it feels that we're throwing the baby out
with the bath water…

I do think we can do semver with just a minimal amount of dev guidelines in
place, to great benefit to users (and for ourselves).



> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>


The following aspects remain open questions for me…
 - if there's no such features, or anything breaking compatibility, isn't
there benefit in releasing a minor,
 - can we better indicate to users the upgrade path (and how we simplify
which upgrade paths we have to support),
 - the practice of deprecating an API one release and then removing it the
following,
 - we have CQL, Native Protocol, SSTable versioning, can they tie in to our
semver (especially their majors, which are also about compatibility)

I would have thought we have enough here to provide a set of guidelines to
the dev community about when a release is either a major or minor. The
missing piece here is how do we apply a branching strategy. I would suggest
the same branching strategy that we would do under your suggestion of
, so that the decision about a release being a major or a
minor can be lazy made. It may be in practice that this starts off with
every release being a major, as you have suggested, but we would keep the
minor numbers and semver there to use when we see fit. If our practices
improve, with the dev guidelines in place, we may see that releases become
mostly minors.

And I see this increases relevance if we introduce more SPIs into the
codebase and have a bigger dev ecosystem around us, e.g. storage engine,
compaction, indexes, thin-coordinators… Already today we know we have
consumers of our maven artifacts, and dependency hell is a big part of
semver's value, ref: https://semver.org/



> Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
>


What we can do depends on how much time the community has to contribute.
That is a changing and responsive thing. We can aim for an objective, and
improve/streamline processes and guidelines.

So, my suggestion is to…
 - keep semver,
 - we decide whether a release is major or minor when we agree to cut a
release, and
 - that decision is primarily based on documented dev guidelines.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>


Completely agree with this. But it feels that we're throwing the baby out
with the bath water…

I do think we can do semver with just a minimal amount of dev guidelines in
place, to great benefit to users (and for ourselves).



> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>


The following aspects remain open questions for me…
 - if there's no such features, or anything breaking compatibility, isn't
there benefit in releasing a minor,
 - can we better indicate to users the upgrade path (and how we simplify
which upgrade paths we have to support),
 - the practice of deprecating an API one release and then removing it the
following,
 - we have CQL, Native Protocol, SSTable versioning, can they tie in to our
semver (especially their majors, which are also about compatibility)

I would have thought we have enough here to provide a set of guidelines to
the dev community about when a release is either a major or minor. The
missing piece here is how do we apply a branching strategy. I would suggest
the same branching strategy that we would do under your suggestion of
, so that the decision about a release being a major or a
minor can be lazy made. It may be in practice that this starts off with
every release being a major, as you have suggested, but we would keep the
minor numbers and semver there to use when we see fit. If our practices
improve, with the dev guidelines in place, we may see that releases become
mostly minors.

And I see this increases relevance if we introduce more SPIs into the
codebase and have a bigger dev ecosystem around us, e.g. storage engine,
compaction, indexes, thin-coordinators… Already today we know we have
consumers of our maven artifacts, and dependency hell is a big part of
semver's value, ref: https://semver.org/



> Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
>


What we can do depends on how much time the community has to contribute.
That is a changing and responsive thing. We can aim for an objective, and
improve/streamline processes and guidelines.

So, my suggestion is to…
 - keep semver,
 - we decide whether a release is major or minor when we agree to cut a
release, and
 - that decision is primarily based on documented dev guidelines.

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

 I am a bit scared of a continuous delivery approach for a database due to
the lack of guarantee on the APIs and protocols as you mentioned. On the
other hand an annual major release cadence seems a bit too inflexible for
me.
It makes sense to me to ensure that we release at least one major version
per year, nevertheless I believe that if we see that a significant amount
of work has been released (for example 3 or 4 CEPs) we should allow
ourselves to cut a release sooner. Making an official release would force
us to go beyond our normal testing ensuring that we did not introduce new
defects that our tests could have missed. Interaction between features is
often a weak spot from the testing point of view.

What do you think?


On Thu, Jan 28, 2021 at 1:25 PM Benedict Elliott Smith 
wrote:

> We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>
> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>
> This happens to accord with my preference, namely that we eliminate the
> concept of a minor release in semver terms. We have feature releases and
> patch releases. i.e., 4.0's first bug fix release is 4.1, and in a year we
> ship 5.0.  There has been support voiced for this in a couple of forums
> (including on this list back in 2019), but it was perhaps never fully
> discussed/settled.
>
> > Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
> Perhaps it wouldn't make sense if we aim for true continuous delivery of
> trunk. However, there is value in flexibility to experiment/revisit
> decisions before committing to APIs and feature behaviours long term. By
> providing continuous delivery of builds that do not guarantee API stability
> for new features/APIs, users that are able to accept some small risk in
> this regard (e.g. during development, or where they do not intend to use
> the new features) may still benefit from access to high quality releases
> quickly, and the project gets more rapid feedback.
>
> Perhaps we can have a flexible approach though, wherein we have continuous
> delivery of release candidates, and on arbitrary timelines cut releases
> that create API-stability points, and periodically nominate such releases
> to receive 3+ years of support.
>
>
>
> On 28/01/2021, 11:42, "Mick Semb Wever"  wrote:
>
> > I'd like to pair this with stricter merge criteria, so that we
> maintain a
> ~shippable trunk, [snip]. We might have to get happy with reverting
> commits
> that break things.
>
>
> Yes and yes! The work we have done, started on, and undercovered in
> the 4.0
> Quality Testing Epics should continue.
>
> Our CI systems have also improved. Folk are using both circleci and
> ci-cassandra, and i think the combination brings an advantage.  Though
> there's still a lot to do. CircleCI doesn't cover everything, and
> with ci-cassandra there are a few things still to do. For example:
> arm64,
> jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
> pipeline. Jira tickets exist for these. Another issue we have is
> reliably
> identifying flaky tests and test history. All test results and logs
> are now
> getting stored in nightlies.a.o, so the data is there to achieve it,
> but
> searching it remains overly raw.
>
> If such efforts continue, as they have, we should definitely be able to
> avoid repeating the feature freeze requirement.
>
>
> > My preference is for a simple annual major release cadence, with
> minors
> as necessary. This is simple for the user community and developer
> community: support = x versions = x years.
>
> This raises a number of questions for me.
>
> Why make a release at a fixed time each year?
> The idea of one major release a year contradicts in practice any
> efforts
> towards a stable-trunk. Stable-trunk is more popularly associated with
> Continuously Delivered (CD) codebases. Yearly releases are not quite
> that,
> and I can't see a stricter merge criteria compensating enough. I have
> put
> effort into the release process, and encouraged the community to have
> more
> active release managers, so that when we need a release we can get
> one. We
> should be looking into cutting patch releases as often as possible.
>
> For how many years shall we support major versions?
> Currently we maintain three release branches, plus one limited to
> security
> issues, and the oldest has been supported for 5 years. I think 5 years
> is
> too long for the 

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

We have had a very problematic history with release versioning, such that our 
users probably think the numbers are meaningless.

However, in the new release lifecycle document (and in follow-up discussions 
around qualifying releases) we curtail _features_ once a release is GA, and 
also stipulate that a new major version is associated with a release.

This happens to accord with my preference, namely that we eliminate the concept 
of a minor release in semver terms. We have feature releases and patch 
releases. i.e., 4.0's first bug fix release is 4.1, and in a year we ship 5.0.  
There has been support voiced for this in a couple of forums (including on this 
list back in 2019), but it was perhaps never fully discussed/settled.

> Why make a release at a fixed time each year?
> Stable-trunk is more popularly associated with Continuously Delivered (CD) 
> codebases

We need to pick some points in time to provide stability/patch support for, and 
an annual cadence provides some certainty to the community.  Perhaps it 
wouldn't make sense if we aim for true continuous delivery of trunk. However, 
there is value in flexibility to experiment/revisit decisions before committing 
to APIs and feature behaviours long term. By providing continuous delivery of 
builds that do not guarantee API stability for new features/APIs, users that 
are able to accept some small risk in this regard (e.g. during development, or 
where they do not intend to use the new features) may still benefit from access 
to high quality releases quickly, and the project gets more rapid feedback.

Perhaps we can have a flexible approach though, wherein we have continuous 
delivery of release candidates, and on arbitrary timelines cut releases that 
create API-stability points, and periodically nominate such releases to receive 
3+ years of support. 



On 28/01/2021, 11:42, "Mick Semb Wever"  wrote:

> I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, [snip]. We might have to get happy with reverting commits
that break things.


Yes and yes! The work we have done, started on, and undercovered in the 4.0
Quality Testing Epics should continue.

Our CI systems have also improved. Folk are using both circleci and
ci-cassandra, and i think the combination brings an advantage.  Though
there's still a lot to do. CircleCI doesn't cover everything, and
with ci-cassandra there are a few things still to do. For example: arm64,
jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
pipeline. Jira tickets exist for these. Another issue we have is reliably
identifying flaky tests and test history. All test results and logs are now
getting stored in nightlies.a.o, so the data is there to achieve it, but
searching it remains overly raw.

If such efforts continue, as they have, we should definitely be able to
avoid repeating the feature freeze requirement.


> My preference is for a simple annual major release cadence, with minors
as necessary. This is simple for the user community and developer
community: support = x versions = x years.

This raises a number of questions for me.

Why make a release at a fixed time each year?
The idea of one major release a year contradicts in practice any efforts
towards a stable-trunk. Stable-trunk is more popularly associated with
Continuously Delivered (CD) codebases. Yearly releases are not quite that,
and I can't see a stricter merge criteria compensating enough. I have put
effort into the release process, and encouraged the community to have more
active release managers, so that when we need a release we can get one. We
should be looking into cutting patch releases as often as possible.

For how many years shall we support major versions?
Currently we maintain three release branches, plus one limited to security
issues, and the oldest has been supported for 5 years. I think 5 years is
too long for the current community and would suggest bringing it down to 3
years. The project is maturing, and along with efforts towards a
stable-trunk, I would expect upgrades to be getting easier. Asking users to
upgrade at least once every three years shouldn't be a big deal for an OSS
project.


> I understood us to have agreed to drop semver, because our major/minor
history has been a meaningless distinction…


I am not sure that I understand that point, is there reference to this
agreement?
Not releasing minor versions doesn't mean we drop semver, we still have the
three numbers there in our versions. In your first reply you wrote that we
would do "minors as necessary", what were your thoughts on what a minor was
there? Was it just a relabelling of patch versions?

Now that we have our Release Lifecycle guidelines defined, which included
discussions on compatibility issues, isn't it a good 

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

> I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, [snip]. We might have to get happy with reverting commits
that break things.


Yes and yes! The work we have done, started on, and undercovered in the 4.0
Quality Testing Epics should continue.

Our CI systems have also improved. Folk are using both circleci and
ci-cassandra, and i think the combination brings an advantage.  Though
there's still a lot to do. CircleCI doesn't cover everything, and
with ci-cassandra there are a few things still to do. For example: arm64,
jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
pipeline. Jira tickets exist for these. Another issue we have is reliably
identifying flaky tests and test history. All test results and logs are now
getting stored in nightlies.a.o, so the data is there to achieve it, but
searching it remains overly raw.

If such efforts continue, as they have, we should definitely be able to
avoid repeating the feature freeze requirement.


> My preference is for a simple annual major release cadence, with minors
as necessary. This is simple for the user community and developer
community: support = x versions = x years.

This raises a number of questions for me.

Why make a release at a fixed time each year?
The idea of one major release a year contradicts in practice any efforts
towards a stable-trunk. Stable-trunk is more popularly associated with
Continuously Delivered (CD) codebases. Yearly releases are not quite that,
and I can't see a stricter merge criteria compensating enough. I have put
effort into the release process, and encouraged the community to have more
active release managers, so that when we need a release we can get one. We
should be looking into cutting patch releases as often as possible.

For how many years shall we support major versions?
Currently we maintain three release branches, plus one limited to security
issues, and the oldest has been supported for 5 years. I think 5 years is
too long for the current community and would suggest bringing it down to 3
years. The project is maturing, and along with efforts towards a
stable-trunk, I would expect upgrades to be getting easier. Asking users to
upgrade at least once every three years shouldn't be a big deal for an OSS
project.


> I understood us to have agreed to drop semver, because our major/minor
history has been a meaningless distinction…


I am not sure that I understand that point, is there reference to this
agreement?
Not releasing minor versions doesn't mean we drop semver, we still have the
three numbers there in our versions. In your first reply you wrote that we
would do "minors as necessary", what were your thoughts on what a minor was
there? Was it just a relabelling of patch versions?

Now that we have our Release Lifecycle guidelines defined, which included
discussions on compatibility issues, isn't it a good time to also define
what "incompatible API changes" is for us?

If we define "incompatible API changes" then each release should be simple
enough to know whether it is going to be a major or minor. This also comes
back to our support window, if we have a three year support window and only
yearly major versions, does that not mean we are then asking users to
perform three upgrades every three years?

I am pretty sure I would favour defining what "incompatible API changes"
means for us, and aim for only one major every three years but let the PMC
make exceptions as we go along when we see fit, knowing the cost the
exception comes with.

We are already getting better at identifying what incompatibilities are, as a
requirement we have put on ourselves with the Release Lifecycle guidelines.
  And I assume that pushing for a stable-trunk effectively implies some
semver like strategy, allowing us to re-use our identification of
incompatibilities. In short, if we are making ourselves better at
identifying incompatibilities (because of the Release Lifecycle), why would
we not re-use that to benefit the user?

Re: [DISCUSS] When to stop supporting Python 2

[Benjamin Lerer]

Considering the issue with pip. I agree that we should remove support for
3.0 and ensure that python 3 is supported by 3.11.

On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis  wrote:

> Python 2 was EOLed over a year ago.  I think it's fine to (1) require
> python 3 to run cqlsh and (2) remove code that supports python 2 whenever
> it's convenient.
>
> Angelo has the right idea that rather than trying to finesse a deprecation
> cycle into 4.0 at this late date, a better migration path can be provided
> by backporting python3 support to 3.11.
>
> On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams 
> wrote:
>
> > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg
> >  wrote:
> > > I want to emphasize here: to my way of thinking, "dropping support" at
> > this
> > > juncture is just a matter of documenting it, and maybe introducing a
> > > warning. We don't need to *remove* support for python2. It will
> continue
> > to
> > > work as-is. This would just guide us in deciding whether to work on
> flaws
> > > that are python2-specific, and whether new things are developed with
> > > backwards compatibility as a forcing concern.
> >
> > Actually, I think we have to go a little bit further, and at least as
> > far as packaging is concerned, remove support for python2.  Recently
> > pip updated to 21.0 and removed python2 support, which broke any
> > builds that built artifacts requiring pip.  We now pin pip:
> >
> >
> https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8
> > to get around this, but highlights that we too need to move away from
> > anything using python2.  So while we would not modify code to *remove*
> > python2 support, you would have to invoke python2 on the code in your
> > own way, since the packages would depend on python3.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>