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.
I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, and we cut a release at ~the same time every year, whatever
features are merged. We might have to get happy with reverting commits that
break things.
I think faster cadences impose too much burden on the developer community for
maintenance and the user community for both upgrades and making sense of what's
going on. I think slower cadences collapse, as the release window begins to
collect too many hopes and dreams.
My hope is that we get to a point where snapshots of trunk are safe to run, and
that major contributors are ahead of the release window for internal
consumption, rather than behind - this might also alleviate pressure for
hitting release windows with features.
On 26/01/2021, 13:56, "Benjamin Lerer" <benjamin.le...@datastax.com> wrote:
Hi everybody
It seems that there is a need to discuss how we will deal with releases
after 4.0
We are now relatively close from the 4.0 RC release so it make sense to me
to start discussing that subject especially as it has some impact on some
things like dropping support for python 2
The main questions are in my opinion:
1) What release cadence do we want to use for major/minor versions?
2) How do we plan to ensure the quality of the releases?
It might make sense to try a release cadence and see how it works out in
practice revisiting our decision if we feel the need for it.
One important thing to discuss with the cadence is the amount of time we
want to support the releases. 2.2 has been supported for more than 5 years,
we might not be able to support releases for a similar time frame if we
release a version every 6 months for example.
To be sure that we are all on the same page regarding what minor and major
versions are and their naming: 4.1 would be a minor version (improvements
and features that don't break compatibility) and 5.0 would be a major
version (compatibility breakages)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
