> 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" <m...@apache.org> 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
<major.patch>, 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
