After carefully reading the thread, it seems to me we need to find the
right balance between:
1) users' understanding about versions; also usability
Please, people, share your experience and feedback, we want to hear it!
2) no breaking changes for the ecosystem (or at least as little as possible)
3) efficient release management (minimal maintenance).

A few quotes from the thread:

"This can be helpful as the codebase (and drivers) does not like funky
versions (like putting in pre-release or vendor labels), as we want to be
inclusive to the ecosystem."
I would advocate for no breaking changes. Let's leave the people to enjoy
4.0 and beyond in peace if there is no urgency to break stuff. :-)

"I don't think this is a major concern (today we go from 3.0 to 3.11 from
ticktock, after all) since the important thing is that the version is
larger and lexicographically sorts after the earlier one."
Seems like some of us didn't even realize that happened. Please raise your
hand if you did and struggled. I want to hear your stories in order to
evaluate the potential threats.

"For the release manager this is a simpler approach (not having to rollback
version numbers and changelogs), and for those using development published
artefacts (nightlies, staging, etc) (not having versions clobbered).
Release manager practices aside, as a user I agree with Brandon, what
matters is the version is greater and whether major/minor/patch numbers are
greater."
This is a very important point. Release management is time consuming enough
and from what I've seen there are not many people who have that time to
dedicate it. If there are suggestions for different ways to improve that
experience, please, share them.

"During the lead up to 4.0.0 there was plenty of headache and fixes going
in to deal with how we parse version numbers in different places and
alpa|beta|rc etc. I would rather bump the versions during the dev cycle and
work on fixing it, than have that headache again at release time. I also
feel for third-parties that have to parse our own way of versioning."
Thank you Mick for sharing again the release management point of view. It
is always a challenge to find a release manager who will have the time to
spend on those things and often those efforts are not even really visible
so it is easy to underestimate them. (All the break&fix that goes with it)

On Thu, 16 Dec 2021 at 19:19, bened...@apache.org <bened...@apache.org>
wrote:

> 4.1.0-pre1 sounds good to me.
>
> From: Jeremiah D Jordan <jeremiah.jor...@gmail.com>
> Date: Thursday, 16 December 2021 at 16:37
> To: dev@cassandra.apache.org <dev@cassandra.apache.org>
> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version
> bumps
> If we want to have “called out development snapshots” then I think we need
> some way to distinguish build from those commits the from ongoing work in
> the version number that is in the build file.  I do not think the
> “development snapshots” being 4.1.0-SNAPSHOT and current trunk also being
> 4.1.0-SNAPSHOT achieves that goal.
>
> How we accomplish that, I don’t have any preference.  Bumping the version
> number such that trunk becomes 4.2.0-SNAPSHOT is a pretty simple way to
> accomplish it.
>
> Another option would be to push and tag a commit outside of the trunk
> branch that has the version as 4.1.0-pre1 or something.  From my look at
> the CassandraVersion code something after SNAPSHOT will not parse
> correctly, -SNAPSHOT needs to be the last thing.  So 4.1.0-pre1-SNAPSHOT is
> valid, 4.1.0-SNAPSHOT-pre1 is not.
>
> -Jeremiah
>
> > On Dec 16, 2021, at 9:33 AM, bened...@apache.org wrote:
> >
> > I don’t really see the advantage to this over 4.1.0-SNAPSHOT1
> >
> > From: Mick Semb Wever <m...@apache.org>
> > Date: Thursday, 16 December 2021 at 15:04
> > To: dev@cassandra.apache.org <dev@cassandra.apache.org>
> > Subject: [DISCUSS] Periodic snapshot publishing with minor version bumps
> > Back in January¹ we agreed to do periodic snapshot publishing, as we
> > move to yearly major+minor releases. But (it's come to light²) it
> > wasn't clear how we would do that.
> >
> > ¹) https://lists.apache.org/thread/vzx10600o23mrp9t2k55gofmsxwtng8v
> > ²) https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900
> >
> >
> > The following is a proposal on doing such snapshot publishing by
> > bumping the minor version number.
> >
> > The idea is to every ~quarter in trunk bump the minor version in
> > build.xml. No release or branch would be cut. But the last SHA on the
> > previous snapshot version can be git tagged. It does not need to
> > happen every quarter, we can make that call as we go depending on how
> > much has landed in trunk.
> >
> > The idea of this approach is that it provides a structured way to
> > reference these periodic published snapshots. That is, the semantic
> > versioning that our own releases abide by extends to these periodic
> > snapshots. This can be helpful as the codebase (and drivers) does not
> > like funky versions (like putting in pre-release or vendor labels), as
> > we want to be inclusive to the ecosystem.
> >
> > A negative reaction of this approach is that our released versions
> > will jump minor versions. For example, next year's release could be
> > 4.3.0 and users might ask what happened to 4.1 and 4.2. This should
> > only be a cosmetic concern, and general feedback seems to be that
> > users don't care so long as version numbers are going up, and that we
> > use semantic versioning so that major version increments mean
> > something (we would never jump a major version).
> >
> > A valid question is how would this impact our supported upgrade paths.
> > Per semantic versioning any 4.x to 4.y (where y > x) is always safe,
> > and any major upgrade like 4.z to 5.x is safe (where z is the last
> > 4.minor). Nonetheless we should document this to make it clear and
> > explicit how it works (and that we are adhering to semver).
> > https://semver.org/
> >
> > What are people's thoughts on this?
> > Are there objections to bumping trunk so that base.version=4.2 ? (We
> > can try this trunk and re-evaluate after our next annual release.)
> >
> > ---------------------------------------------------------------------
> > 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
>

Reply via email to