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" <m...@apache.org> 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 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
