Perhaps we could also consider quarterly "develop" releases, so that we have
pressure to maintain a shippable trunk? This provides some opportunity for more
releases without incurring the project maintenance costs or user coordination
costs. Something like a feature-incomplete mid-cycle RC, that a user wanting
shiny features can grab, providing feedback throughout the development cycle.
On 26/01/2021, 14:11, "Benedict Elliott Smith" <bened...@apache.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
