subject:"Re\: \[DISCUSS\] Periodic snapshot publishing with minor version bumps"

> If we simply used CassandraVersion (which is broadly equivalent, but 
> standard’s compliant)

Actually it’s got the same issue, but it’s a one line fix.

From: Mick Semb Wever 
Date: Tuesday, 21 December 2021 at 22:06
To:
Cc: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> These can be further subdivided to:
>
> A1.   4.1.0-PRE{1,2,3,4} -> 4.1.0-alpha1
> A2.   4.1.0-alpha{1,2,3,4} -> 4.1.0-alpha5
> B1. 4.1.{0,1,2,3} -> 4.1.4-alpha1
> B2. 4.{1,2,3,4} -> 4.5.0-alpha1
> B3. 4.{1,2,3,4} -> 5.0.0-alpha1
> C1. 4.1.{0,1,2,3}-pre -> 4.1.4-alpha1
> C2. 4.{1,2,3,4}.0-pre -> 4.5.0-alpha1
> C3. 4.{1,2,3,4}.0-pre -> 5.0.0-alpha1
>

(A) does not work with the codebase as it is today. It requires additional work.

(B) has not been suggested anywhere in the thread, so I find it odd
that it was proposed.

(C2) is the original proposal. (Though the build metadata suffix is
not "pre", it is either SNAPSHOT or a timestamp.)

(B3) and (C3) doesn't follow SemVer.

(C1) is interesting, I wouldn't object to it, though share similar
initial reaction to Josh.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

>The problem I have with (A2) is that third-parties, vendors, etc, can only 
>clumsily extend and continue on those version numbers. 4.1.0-alpha2-myvendor-3 
>is awkward.

Do you intend to use this capability, and if so could you point out where you 
highlighted this motivation previously?

These snapshots are not releases for broad consumption, and definitely are not 
meant to be consumed by third-parties for release as Cassandra-like software. 
Third-parties releasing such software are _not offering Apache Cassandra_. 
Helping these entities to release software that might be interpreted as Apache 
Cassandra, and to be consistent with Apache Cassandra’s release schedule, is 
almost certainly a problem with this approach, not an asset. Such software 
should have its own versioning that is distinct from Apache Cassandra.

>(B) has not been suggested anywhere in the thread, so I find it odd that it 
>was proposed.

Ok, I misunderstood your proposal, I had not anywhere seen you intended to 
include a -SNAPSHOT suffix. C{1,2,3} can be interpreted as supporting -SNAPSHOT 
rather than -pre, and I guess (B) will get very few votes, and/or can be 
ignored.

> (A) does not work with the codebase as it is today. It requires additional 
> work.

This is untrue. A2 requires no additional work, and A1’s only issue is that we 
use a standard’s non-compliant Semver implementation that was introduced in May 
for some unspecified reason. If we simply used CassandraVersion (which is 
broadly equivalent, but standard’s compliant) everything would seem to be fine.


From: Mick Semb Wever 
Date: Tuesday, 21 December 2021 at 22:06
To:
Cc: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> These can be further subdivided to:
>
> A1.   4.1.0-PRE{1,2,3,4} -> 4.1.0-alpha1
> A2.   4.1.0-alpha{1,2,3,4} -> 4.1.0-alpha5
> B1. 4.1.{0,1,2,3} -> 4.1.4-alpha1
> B2. 4.{1,2,3,4} -> 4.5.0-alpha1
> B3. 4.{1,2,3,4} -> 5.0.0-alpha1
> C1. 4.1.{0,1,2,3}-pre -> 4.1.4-alpha1
> C2. 4.{1,2,3,4}.0-pre -> 4.5.0-alpha1
> C3. 4.{1,2,3,4}.0-pre -> 5.0.0-alpha1
>


(A) does not work with the codebase as it is today. It requires additional work.

(B) has not been suggested anywhere in the thread, so I find it odd
that it was proposed.

(C2) is the original proposal. (Though the build metadata suffix is
not "pre", it is either SNAPSHOT or a timestamp.)

(B3) and (C3) doesn't follow SemVer.

(C1) is interesting, I wouldn't object to it, though share similar
initial reaction to Josh.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> (A) does not work with the codebase as it is today. It requires additional 
> work.

Correction: (A1) does not work with the codebase as it is today. It
requires additional work.

The problem I have with (A2) is that third-parties, vendors, etc, can
only clumsily extend and continue on those version numbers.
4.1.0-alpha2-myvendor-3 is awkward. Especially if myvendor has chosen
to test alpha2 and officially support it. If we push them off to do
their own versioning, how does that impact drivers and such,
especially if it's a distribution consisting of otherwise open
patches?

I appreciate Benedict that you've raised these examples.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> These can be further subdivided to:
>
> A1.   4.1.0-PRE{1,2,3,4} -> 4.1.0-alpha1
> A2.   4.1.0-alpha{1,2,3,4} -> 4.1.0-alpha5
> B1. 4.1.{0,1,2,3} -> 4.1.4-alpha1
> B2. 4.{1,2,3,4} -> 4.5.0-alpha1
> B3. 4.{1,2,3,4} -> 5.0.0-alpha1
> C1. 4.1.{0,1,2,3}-pre -> 4.1.4-alpha1
> C2. 4.{1,2,3,4}.0-pre -> 4.5.0-alpha1
> C3. 4.{1,2,3,4}.0-pre -> 5.0.0-alpha1
>


(A) does not work with the codebase as it is today. It requires additional work.

(B) has not been suggested anywhere in the thread, so I find it odd
that it was proposed.

(C2) is the original proposal. (Though the build metadata suffix is
not "pre", it is either SNAPSHOT or a timestamp.)

(B3) and (C3) doesn't follow SemVer.

(C1) is interesting, I wouldn't object to it, though share similar
initial reaction to Josh.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-21 Thread Joshua McKenzie

A{1,2},C{3,2,1},B{3,2,1}

I'm very strongly in favor of some permutation of A or the 3rd on B and C
due to the release at a .0 version.

I've never heard of a project versioning otherwise (happy to have examples
pointed out). I'm a big fan of prior art / settled law / following idioms.

I find the non .0 releases confusing and upgrade paths would be
non-intuitive for non-power users (and even power users would likely have
to check a reference...)

On Tue, Dec 21, 2021 at 2:45 PM Mick Semb Wever  wrote:

> > The purpose of indicative votes is to seek input from the broader
> community. There is no deadline, it is not an official vote, and can run
> across the holiday period. Discussion can continue in parallel, …
>
> Fair enough :-)
>

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

The purpose of indicative votes is to seek input from the broader community. 
There is no deadline, it is not an official vote, and can run across the 
holiday period. Discussion can continue in parallel, but I do not get the 
impression many others are very invested in this discussion. Certainly, I have 
said all I think needs to be said in support of my position. You have expressed 
your concerns repeatedly also; anybody who is interested is likely well aware 
of your position.


From: Mick Semb Wever 
Date: Tuesday, 21 December 2021 at 19:25
To:
Cc: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
Benedict, I had said above in the thread to let it run through til
January, can we please respect that. I do not think the week before
xmas is a great time to push it into a vote, when this is not urgent.

I pointed to the code where we sort versions in a case-insensitive
way. That means PRE1 breaks.
Such breakages occurred in the lead up to 4.0.0, and we would have to
custom patch the semver4j library to make PRE1 be before the alphas.

The test run you provided did not include upgrade tests, and for those
to break you would need a wrongly ordered incompatibility, e.g. from
an alpha to a PRE. It has also been mentioned that drivers (and other
test systems) break.

Currently our snapshots do come with a pre-release label, but they do
come with a build metadata label (being either the explicit "SNAPSHOT"
or the timestamp). This is visible in the nightlies link I provided.
So we do have a precedence in place to distinguish between released
versions and snapshot builds, I say let's continue that.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

Benedict, I had said above in the thread to let it run through til
January, can we please respect that. I do not think the week before
xmas is a great time to push it into a vote, when this is not urgent.

I pointed to the code where we sort versions in a case-insensitive
way. That means PRE1 breaks.
Such breakages occurred in the lead up to 4.0.0, and we would have to
custom patch the semver4j library to make PRE1 be before the alphas.

The test run you provided did not include upgrade tests, and for those
to break you would need a wrongly ordered incompatibility, e.g. from
an alpha to a PRE. It has also been mentioned that drivers (and other
test systems) break.

Currently our snapshots do come with a pre-release label, but they do
come with a build metadata label (being either the explicit "SNAPSHOT"
or the timestamp). This is visible in the nightlies link I provided.
So we do have a precedence in place to distinguish between released
versions and snapshot builds, I say let's continue that.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

After much discussion, I see three basic categories of approach:

A) distinguish releases using unstable release suffixes only
B) distinguish releases using some version number modification
C) distinguish releases using some version number modification AND unstable 
release suffixes to indicate these builds are unsupported

These can be further subdivided to:

A1.   4.1.0-PRE{1,2,3,4} -> 4.1.0-alpha1
A2.   4.1.0-alpha{1,2,3,4} -> 4.1.0-alpha5
B1. 4.1.{0,1,2,3} -> 4.1.4-alpha1
B2. 4.{1,2,3,4} -> 4.5.0-alpha1
B3. 4.{1,2,3,4} -> 5.0.0-alpha1
C1. 4.1.{0,1,2,3}-pre -> 4.1.4-alpha1
C2. 4.{1,2,3,4}.0-pre -> 4.5.0-alpha1
C3. 4.{1,2,3,4}.0-pre -> 5.0.0-alpha1

I vote, in order of preference, for A{1,2},C{1,2,3},B{1,2,3}


From: Mick Semb Wever 
Date: Tuesday, 21 December 2021 at 15:48
To:
Cc: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> My preference is to get our versioning as standard Semantic Versioning as 
> possible, to avoid any precedence that depends on finely reading through the 
> spec that isn't otherwise popular.  Requiring the ordering of the pre-release 
> tag to be case-sensitive alphanumeric is an example of this, but only one.


I am not comfortable relying upon the pre-release tag being
case-sensitive alphanumerically ordered.

Standardising on lower-case pre-release labels and build metadata can
be beneficial, especially when
cross-platform scenarios are considered.  (One of SemVer author's own words.)

One example implementation exists here (in a library that we do already use)
https://github.com/vdurmont/semver4j/blob/master/src/main/java/com/vdurmont/semver4j/Semver.java#L235

And when it comes to cognitive load, I would question the load of
knowing what the difference between PRE1 and SNAPSHOT is (when there
is none), and why we use a custom pre-release tag on builds that are
not releases.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> Nevertheless, it requires fixes

I have run all tests successfully against 4.1.0-PRE1, without modification[1].

> more importantly requires others in the ecosystem to adapt

There is no such requirement for publishing these as alphas, but without 
evidence to the contrary I doubt the downstream impact of this change will 
greatly exceed the time we are spending discussing this.

> I am not comfortable relying upon the pre-release tag being case-sensitive 
> alphanumerically ordered.

Whereas I am very uncomfortable publishing pre-release snapshots that are not 
marked as such.

I think we’ve hashed this out more than enough, so let’s get some indicative 
votes to determine which one the community endorses. I will send a separate 
email for that purpose.

[1] 
https://app.circleci.com/pipelines/github/belliottsmith/cassandra?branch=pre1=all




From: Mick Semb Wever 
Date: Tuesday, 21 December 2021 at 15:48
To:
Cc: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> My preference is to get our versioning as standard Semantic Versioning as 
> possible, to avoid any precedence that depends on finely reading through the 
> spec that isn't otherwise popular.  Requiring the ordering of the pre-release 
> tag to be case-sensitive alphanumeric is an example of this, but only one.


I am not comfortable relying upon the pre-release tag being
case-sensitive alphanumerically ordered.

Standardising on lower-case pre-release labels and build metadata can
be beneficial, especially when
cross-platform scenarios are considered.  (One of SemVer author's own words.)

One example implementation exists here (in a library that we do already use)
https://github.com/vdurmont/semver4j/blob/master/src/main/java/com/vdurmont/semver4j/Semver.java#L235

And when it comes to cognitive load, I would question the load of
knowing what the difference between PRE1 and SNAPSHOT is (when there
is none), and why we use a custom pre-release tag on builds that are
not releases.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> My preference is to get our versioning as standard Semantic Versioning as 
> possible, to avoid any precedence that depends on finely reading through the 
> spec that isn't otherwise popular.  Requiring the ordering of the pre-release 
> tag to be case-sensitive alphanumeric is an example of this, but only one.


I am not comfortable relying upon the pre-release tag being
case-sensitive alphanumerically ordered.

Standardising on lower-case pre-release labels and build metadata can
be beneficial, especially when
cross-platform scenarios are considered.  (One of SemVer author's own words.)

One example implementation exists here (in a library that we do already use)
https://github.com/vdurmont/semver4j/blob/master/src/main/java/com/vdurmont/semver4j/Semver.java#L235

And when it comes to cognitive load, I would question the load of
knowing what the difference between PRE1 and SNAPSHOT is (when there
is none), and why we use a custom pre-release tag on builds that are
not releases.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

(Paulo)
The proposal is not using minor versions to represent snapshots (see the
summary below).

> I think we can overcome any technical limitations

We can, but this is about more than just us (see below).

(Benedict)
> What’s so different about using 4.1.0 that permits avoiding extra work?
> …
> I’m afraid I’m still flummoxed by this. Could you enumerate precisely
what makes this proposal not work, as I still don’t see it?

By "proposals that work" I mean those that will work today with the
codebase as it is. Your proposal is possible. Nevertheless, it requires
fixes (more than just CassandraVersion), and more importantly requires
others in the ecosystem to adapt.

My preference is to get our versioning as standard Semantic Versioning as
possible, to avoid any precedence that depends on finely reading through
the spec that isn't otherwise popular. Requiring the ordering of the
pre-release tag to be case-sensitive alphanumeric is an example of this,
but only one.

This (my) proposal is intended to be very simple.
All we are talking about is the following change

a) tag last 4.1 sha

git tag cassandra-4.1-dev

b) and patch build.xml:

-
+

That's it. No release exists. No announcement made.

We can do a deploy of the last 4.1 snapshots to
https://repository.apache.org/content/repositories/snapshots/
And we can put dev packages of the last 4.1 snapshot onto
https://dist.apache.org/repos/dist/dev/cassandra/ (if we want to*).

This enables our ecosystem and users to start dev testing trunk at a fixed
point. Without anyone ever saying that these have gone from
snapshot->alpha just the same as the snapshot artefacts found in nightlies,
e.g.
https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-artifacts/977/Cassandra-trunk-artifacts/jdk=jdk_1.8_latest,label=cassandra/build/

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-21 Thread Paulo Motta

I dislike the idea of using minors to represent snapshot releases because I
think skipping final release numbers can confuse the vast majority of
non-power users which do not use snapshot releases.

I like the idea of using pre-release tags (ie. alpha1, alpha2, or PRE1,
PRE2, etc) for snapshot releases, and I think we can overcome any technical
limitations which may be preventing us from adopting this scheme in order
to reduce the cognitive burden of users to reason about release numbering
without needing to worry about intermediate experimental releases.

Em ter., 21 de dez. de 2021 às 11:21, Henrik Ingo 
escreveu:

> Just some observations from the proposal and reading the thread. I'm not
> arguing for any one in particular.
>
> 1) Always increase first digit for real releases
>
> The potential for confusion (which versions are stable releases?) can be
> avoided by following Mick's proposal + always increasing the first number
> for actual major releases. (Maybe this isn't exactly SemVer though? But it
> seems it would work for what the project wants to do.) Examples:
>
> 4.0.0 (major release), 4.0.1, 4.0.2... (bug fixes only). 4.1.0, 4.2.0,
> 4.3.0... (quarterly snapshots), 5.0.0 (next major release)
>
> Note that this would also leave an opportunity for a 4.1.1, should someone
> wish to release a fix for one of the snapshot releases.
>
> 2) Use alpha for snapshots
>
> The project could choose to use 4.1.0-alpha1, 4.1.0-alpha2, 4.1.0-alpha3
> for the snapshots. Note that this doesn't prevent from also releasing the
> traditional alpha releases prior to the major release, but those would then
> be alpha3, alpha4...
>
>
> henrik
>
>
>
>
>
>
>
>
>
> On Thu, Dec 16, 2021 at 5:04 PM Mick Semb Wever  wrote:
>
>> 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://urldefense.com/v3/__https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11i0B5_r-w$
>>
>>
>> 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://urldefense.com/v3/__https://semver.org/__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11idIYkMUw$
>>
>> 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
>>
>>
>
> --
>
> Henrik Ingo
>
> +358 40 569 7354 <358405697354>
>
> [image: Visit us online.]   [image: Visit us
> on Twitter.]   [image: Visit us on
> YouTube.]
> 
>   [image: Visit my LinkedIn profile.]
> 
>

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-21 Thread Henrik Ingo

Just some observations from the proposal and reading the thread. I'm not
arguing for any one in particular.

1) Always increase first digit for real releases

The potential for confusion (which versions are stable releases?) can be
avoided by following Mick's proposal + always increasing the first number
for actual major releases. (Maybe this isn't exactly SemVer though? But it
seems it would work for what the project wants to do.) Examples:

4.0.0 (major release), 4.0.1, 4.0.2... (bug fixes only). 4.1.0, 4.2.0,
4.3.0... (quarterly snapshots), 5.0.0 (next major release)

Note that this would also leave an opportunity for a 4.1.1, should someone
wish to release a fix for one of the snapshot releases.

2) Use alpha for snapshots

The project could choose to use 4.1.0-alpha1, 4.1.0-alpha2, 4.1.0-alpha3
for the snapshots. Note that this doesn't prevent from also releasing the
traditional alpha releases prior to the major release, but those would then
be alpha3, alpha4...


henrik









On Thu, Dec 16, 2021 at 5:04 PM Mick Semb Wever  wrote:

> 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://urldefense.com/v3/__https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11i0B5_r-w$
>
>
> 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://urldefense.com/v3/__https://semver.org/__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11idIYkMUw$
>
> 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
>
>

-- 

Henrik Ingo

+358 40 569 7354 <358405697354>

[image: Visit us online.]   [image: Visit us on
Twitter.]   [image: Visit us on YouTube.]

  [image: Visit my LinkedIn profile.]

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-17 Thread bened...@apache.org

> I would like to point out that the code and tests do not support "pre" as a
pre-release label. 4.1.0-pre1 would break the code.

If true this can easily be fixed, but AFAICT CassandraVersion is happy to parse 
this just fine so I doubt there would be many breakages.

> using a pre-release version needs a label that is alphanumerically before
"alpha"

4.0.0-PRE1

> not having to rollback version numbers and changelogs

What is unique about this situation versus alpha, beta and rc? Because these 
are again much more common, so whatever we do to handle these can surely be 
applied here? Why can’t we leave in 4.0.0-PRE1 changelog and release notes, if 
this is such a big deal? What’s so different about using 4.1.0 that permits 
avoiding extra work?

If this is truly impossible, why not use patch numbers rather than minors (with 
additional PRE1)? i.e. we could go 4.0.0-PRE1, 4.0.1-PRE2, 4.0.2-PRE3, 
4.0.4-alpha. I don’t like this, but I dislike it a lot less than using 
unqualified minors.

> We still have only one proposal on the table that works, as was first
raised in this thread.

I’m afraid I’m still flummoxed by this. Could you enumerate precisely what 
makes this proposal not work, as I still don’t see it?


From: Mick Semb Wever 
Date: Friday, 17 December 2021 at 09:18
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> "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 that goes with it)
>


Thanks for the summary run-through and support Ekaterina, much appreciated.


I would like to point out that the code and tests do not support "pre" as a
pre-release label.
4.1.0-pre1 would break the code.

Furthermore, the pre-release version is alphanumerically sorted, therefore
"pre" would land between the last beta and the first rc version. Such
a proposal
using a pre-release version needs a label that is alphanumerically before
"alpha". And the code would need to be fixed to accept and sort the new
label. Maybe the drivers too, Jeremiah?



"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.



Such a change (replacing takeX with version increments when a vote fails)
wasn't part of my proposal here. It was only meant as anecdotal. It is
still useful to know that this situation can arise for the release manager,
e.g. if the artefacts were accidentally published.



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).
>



We still have only one proposal on the table that works, as was first
raised in this thread.

The only valid objection raised so far is cosmetic, touching on (1). I want
to emphasise that it being cosmetic doesn't make it trivial or to be
ignored: the image of the project belongs to the community; it's an
acceptable objection.  But I hope that objections can be followed up with
working proposals.

Reiterating, the cosmetic change would be that our next yearly release be
4.1 or 4.2 or 5.0 or 5.1 or 5.2 (as we would not be doing more than two
periodic snapshots before next May).

Another concern raised was the released artefacts can have a quality
pre-release label attached (alpha|beta|rc) while other unreleased artefacts
would have no such pre-release label, indicating that the latter has a
stability the former does not. This isn't true: these unreleased periodic
artefacts are only availabl

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-17 Thread Mick Semb Wever

> "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 that goes with it)
>


Thanks for the summary run-through and support Ekaterina, much appreciated.


I would like to point out that the code and tests do not support "pre" as a
pre-release label.
4.1.0-pre1 would break the code.

Furthermore, the pre-release version is alphanumerically sorted, therefore
"pre" would land between the last beta and the first rc version. Such
a proposal
using a pre-release version needs a label that is alphanumerically before
"alpha". And the code would need to be fixed to accept and sort the new
label. Maybe the drivers too, Jeremiah?



"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.



Such a change (replacing takeX with version increments when a vote fails)
wasn't part of my proposal here. It was only meant as anecdotal. It is
still useful to know that this situation can arise for the release manager,
e.g. if the artefacts were accidentally published.



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).
>



We still have only one proposal on the table that works, as was first
raised in this thread.

The only valid objection raised so far is cosmetic, touching on (1). I want
to emphasise that it being cosmetic doesn't make it trivial or to be
ignored: the image of the project belongs to the community; it's an
acceptable objection.  But I hope that objections can be followed up with
working proposals.

Reiterating, the cosmetic change would be that our next yearly release be
4.1 or 4.2 or 5.0 or 5.1 or 5.2 (as we would not be doing more than two
periodic snapshots before next May).

Another concern raised was the released artefacts can have a quality
pre-release label attached (alpha|beta|rc) while other unreleased artefacts
would have no such pre-release label, indicating that the latter has a
stability the former does not. This isn't true: these unreleased periodic
artefacts are only available via dev/snapshot channels. They would be the
same as builds off trunk are today, which currently is "4.1" without any
such pre-release label.

There's no rush on this thread, happy to let it continue through to
January. Thanks for speaking up Ekaterina, I hope others do too.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

4.1.0-pre1 sounds good to me.

From: Jeremiah D Jordan 
Date: Thursday, 16 December 2021 at 16:37
To: 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 
> Date: Thursday, 16 December 2021 at 15:04
> To: 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

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> No. You refer to Pre-release but my statement was about Build Metadata. The
timestamping of snapshots is the latter.

So you agree the proposal is compatible with semver? If so, what’s the problem? 
I’m genuinely perplexed.

> I would rather bump the versions during the dev cycle and work on fixing it

I wouldn’t. I’m surprised to hear we broke things between 3.0 and 4.0, but if 
this is happening then these releases are a great opportunity to prevent those 
kinds of problems, not an opportunity to sidestep them.



From: Mick Semb Wever 
Date: Thursday, 16 December 2021 at 19:00
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
>
> I poked around a tiny bit - Spark and Flink both interpret "periodic" as
> "nightly", and fwiw that's what I'm most familiar with. Ruminating on this
> a bit, the implications of a quarterly (or other cadence) snapshot seem to
> be the developers on a project providing more guarantees of support and/or
> integrity than a nightly release which I don't think is what we're trying
> for here.
>
> So I guess my question: why not keep it at 4.1.0 and have 4.1.0-SNAPSHOT be
> a nightly snapshot, and folks downstream can integrate on whichever cadence
> is most appropriate for them using timestamped builds (monthly, quarterly,
> etc)?



It becomes clumsy and limited distinguishing between Q1 4.1.0-SNAPSHOT and
Q2 4.1.0-SNAPSHOT. Our ecosystem (who are dependent on us for this) and our
versioning just hasn't matured enough yet.
We can rely on the nightly approach and the timestamps in the build
metadata like the example you provide. But we have the challenge that this
breaks code, and we want to keep the ecosystem and vendors close and able
to re-use the same semantic versioning scheme. By ecosystem I'm referring
to drivers, test frameworks, libraries and tools. These (as we know
already) can all parse our version numbers, so there's value in using
semver and keeping it simple.



> What benefit do people gain by having us provide both nightly
> snapshots, quarterly snapshots, and yearly releases? Or only quarterly
> snapshots and yearly releases?
>
> Are we trying to encourage more testing?



Yes. Folk have expressed that they don't have resources to test snapshots
or nightlies. But such quarterlies they could test, and would appreciate
doing so. This in turn benefits us.


Are we looking to provide a more
> "blessed" batch of work for downstream maintainers to integrate with?
>


No. From the community's perspective, this comes with only our stable-trunk
guarantees.
We do not release or distribute them. They are only available via our
snapshot/dev channels.
We are relying on a known ASF precedence here.


> AFAIK we publish 4.0.0-rc1 builds and everyone consumes those just fine,
but if everything is so fragile why is it not more reasonable to fix that?


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.



> > It's not semantic versioning
>
> Thought I’d check this, and this appears to be incorrect.


No. You refer to Pre-release but my statement was about Build Metadata. The
timestamping of snapshots is the latter.

Aside from not breaking code, I'm in favour of re-using a popular
specification, and ensuring our versioning is simple and extendable in the
ecosystem.

My suggestion is that we try this proposal this trunk cycle, and
re-evaluate after our next release.
The positive to this, beyond making a decision on experience, is that it
will help improve the code (and ecosystem)'s ability dealing with version
changes outside of release time putting us in a better position to try
alternatives when we re-evaluate.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Mick Semb Wever

>
> I poked around a tiny bit - Spark and Flink both interpret "periodic" as
> "nightly", and fwiw that's what I'm most familiar with. Ruminating on this
> a bit, the implications of a quarterly (or other cadence) snapshot seem to
> be the developers on a project providing more guarantees of support and/or
> integrity than a nightly release which I don't think is what we're trying
> for here.
>
> So I guess my question: why not keep it at 4.1.0 and have 4.1.0-SNAPSHOT be
> a nightly snapshot, and folks downstream can integrate on whichever cadence
> is most appropriate for them using timestamped builds (monthly, quarterly,
> etc)?



It becomes clumsy and limited distinguishing between Q1 4.1.0-SNAPSHOT and
Q2 4.1.0-SNAPSHOT. Our ecosystem (who are dependent on us for this) and our
versioning just hasn't matured enough yet.
We can rely on the nightly approach and the timestamps in the build
metadata like the example you provide. But we have the challenge that this
breaks code, and we want to keep the ecosystem and vendors close and able
to re-use the same semantic versioning scheme. By ecosystem I'm referring
to drivers, test frameworks, libraries and tools. These (as we know
already) can all parse our version numbers, so there's value in using
semver and keeping it simple.



> What benefit do people gain by having us provide both nightly
> snapshots, quarterly snapshots, and yearly releases? Or only quarterly
> snapshots and yearly releases?
>
> Are we trying to encourage more testing?



Yes. Folk have expressed that they don't have resources to test snapshots
or nightlies. But such quarterlies they could test, and would appreciate
doing so. This in turn benefits us.


Are we looking to provide a more
> "blessed" batch of work for downstream maintainers to integrate with?
>


No. From the community's perspective, this comes with only our stable-trunk
guarantees.
We do not release or distribute them. They are only available via our
snapshot/dev channels.
We are relying on a known ASF precedence here.


> AFAIK we publish 4.0.0-rc1 builds and everyone consumes those just fine,
but if everything is so fragile why is it not more reasonable to fix that?


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.



> > It's not semantic versioning
>
> Thought I’d check this, and this appears to be incorrect.


No. You refer to Pre-release but my statement was about Build Metadata. The
timestamping of snapshots is the latter.

Aside from not breaking code, I'm in favour of re-using a popular
specification, and ensuring our versioning is simple and extendable in the
ecosystem.

My suggestion is that we try this proposal this trunk cycle, and
re-evaluate after our next release.
The positive to this, beyond making a decision on experience, is that it
will help improve the code (and ecosystem)'s ability dealing with version
changes outside of release time putting us in a better position to try
alternatives when we re-evaluate.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Brandon Williams

On Thu, Dec 16, 2021 at 12:39 PM bened...@apache.org
 wrote:
>
> Yes it is, see my prior email.

Yes, sorry, we raced there.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

Yes it is, see my prior email.

Even it weren’t, I would struggle to understand the argument. We publish alpha, 
beta and rc just fine and the world hasn’t collapsed. I can’t imagine anyone 
advocating that we publish these as their own minor versions.

From: Brandon Williams 
Date: Thursday, 16 December 2021 at 17:43
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
On Thu, Dec 16, 2021 at 11:38 AM bened...@apache.org
 wrote:
>
> > Oh yeah, that's a dealbreaker then. Wasn't aware.
>
> Is this a dealbreaker?

It's not semver, so I would say so, unless we want to keep doing that poorly.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Brandon Williams

On Thu, Dec 16, 2021 at 11:38 AM bened...@apache.org
 wrote:
>
> > Oh yeah, that's a dealbreaker then. Wasn't aware.
>
> Is this a dealbreaker?

It's not semver, so I would say so, unless we want to keep doing that poorly.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

> It's not semantic versioning

Thought I’d check this, and this appears to be incorrect. From 
https://semver.org:

A pre-release version MAY be denoted by appending a hyphen and a series of dot 
separated identifiers immediately following the patch version. Identifiers MUST 
comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST 
NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release 
versions have a lower precedence than the associated normal version. A 
pre-release version indicates that the version is unstable and might not 
satisfy the intended compatibility requirements as denoted by its associated 
normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 
1.0.0-x.7.z.92, 1.0.0-x-y-z.–.




From: Mick Semb Wever 
Date: Thursday, 16 December 2021 at 16:31
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> >
> > general feedback seems to be that users don't care so long as version
> > numbers are going up
>
> Curious to hear more about this. It doesn't match my intuition or
> experience running systems but I'm also n=1 and there's a lot of opinions
> in the world.
>
> Leap-frogged by Benedict's response here, but I'm in favor of something
> like:
> 4.1.0-SNAPSHOT-22Q1
> 4.1.0-SNAPSHOT-22Q2
> ...
>
> Keeps lexicographical comparison but also embeds the intent of the release
> and when it hit all in one bundle. And doesn't blow up our minor #'s and
> lead to confusion.
>


It's not semantic versioning, and it breaks the code and drivers.

The proposal is about publishing a semantic version, providing a structure
that is inclusive to the ecosystem and vendors, combined with the
limitations/challenges within the project around what version numbers are
valid.

The SNAPSHOT suffix/label here does not belong to semantic versioning. In
maven repositories it gets replaced with timestamps which is "Build
metadata" (#spec-item-10) for SemVer. Both suffixing and extending this
becomes messy (and again would not be SemVer).

Jumping version numbers can happen when releases cut don't pass
staging/voting are cast aside and a new release with a new version is cut
instead of a "takeX" approach. 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.

I am interested in others PoV, but am seeing this boiling down to a)
extending SemVer to these published dev artefacts (which enables and keeps
close the ecosystem and vendors), and b) accepting that the code and
drivers is fragile with versions and we need to keep it simple.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Joshua McKenzie

>
> it breaks the code and drivers.

b) accepting that the code and drivers is fragile with versions and we need
> to keep it simple.

Oh yeah, that's a dealbreaker then. Wasn't aware.

we agreed to do periodic snapshot publishing

I poked around a tiny bit - Spark and Flink both interpret "periodic" as
"nightly", and fwiw that's what I'm most familiar with. Ruminating on this
a bit, the implications of a quarterly (or other cadence) snapshot seem to
be the developers on a project providing more guarantees of support and/or
integrity than a nightly release which I don't think is what we're trying
for here.

So I guess my question: why not keep it at 4.1.0 and have 4.1.0-SNAPSHOT be
a nightly snapshot, and folks downstream can integrate on whichever cadence
is most appropriate for them using timestamped builds (monthly, quarterly,
etc)? What benefit do people gain by having us provide both nightly
snapshots, quarterly snapshots, and yearly releases? Or only quarterly
snapshots and yearly releases?

Are we trying to encourage more testing? Are we looking to provide a more
"blessed" batch of work for downstream maintainers to integrate with?

(And sorry if it seems like I'm being intentionally obtuse here - just
trying to figure out what outcomes we're trying to drive to inform the
"what's the right cadence for snapshots" discussion)

~Josh

On Thu, Dec 16, 2021 at 11:32 AM Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:

> And per Mick’s comment, we will want to try out what ever special version
> we come up with from a few drivers, and in a rolling upgrade from
> 3.11/4.0.  From my experience in shoving funny version numbers in builds
> there are things you can do that will make version parsing code barf and
> crash stuff.
>
> > On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
> >
> > 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 
> >> Date: Thursday, 16 December 2021 at 15:04
> >> To: 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

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Jeremiah D Jordan

And per Mick’s comment, we will want to try out what ever special version we 
come up with from a few drivers, and in a rolling upgrade from 3.11/4.0.  From 
my experience in shoving funny version numbers in builds there are things you 
can do that will make version parsing code barf and crash stuff.

> On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan  
> wrote:
> 
> 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 
>> Date: Thursday, 16 December 2021 at 15:04
>> To: 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

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Mick Semb Wever

> >
> > general feedback seems to be that users don't care so long as version
> > numbers are going up
>
> Curious to hear more about this. It doesn't match my intuition or
> experience running systems but I'm also n=1 and there's a lot of opinions
> in the world.
>
> Leap-frogged by Benedict's response here, but I'm in favor of something
> like:
> 4.1.0-SNAPSHOT-22Q1
> 4.1.0-SNAPSHOT-22Q2
> ...
>
> Keeps lexicographical comparison but also embeds the intent of the release
> and when it hit all in one bundle. And doesn't blow up our minor #'s and
> lead to confusion.
>


It's not semantic versioning, and it breaks the code and drivers.

The proposal is about publishing a semantic version, providing a structure
that is inclusive to the ecosystem and vendors, combined with the
limitations/challenges within the project around what version numbers are
valid.

The SNAPSHOT suffix/label here does not belong to semantic versioning. In
maven repositories it gets replaced with timestamps which is "Build
metadata" (#spec-item-10) for SemVer. Both suffixing and extending this
becomes messy (and again would not be SemVer).

Jumping version numbers can happen when releases cut don't pass
staging/voting are cast aside and a new release with a new version is cut
instead of a "takeX" approach. 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.

I am interested in others PoV, but am seeing this boiling down to a)
extending SemVer to these published dev artefacts (which enables and keeps
close the ecosystem and vendors), and b) accepting that the code and
drivers is fragile with versions and we need to keep it simple.

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Jeremiah D Jordan

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 
> Date: Thursday, 16 December 2021 at 15:04
> To: 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

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Brandon Williams

On Thu, Dec 16, 2021 at 9:10 AM Mick Semb Wever  wrote:
>
> 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).

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.
If I'm updating a machine via apt/rpm/whatever I may note which
packages are upgrading, but as long as the versions are greater there
isn't much reason to dig further.  Generally when I do that, versions
are being skipped already.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

2021-12-16 Thread Joshua McKenzie

>
> general feedback seems to be that users don't care so long as version
> numbers are going up

Curious to hear more about this. It doesn't match my intuition or
experience running systems but I'm also n=1 and there's a lot of opinions
in the world.

Leap-frogged by Benedict's response here, but I'm in favor of something
like:
4.1.0-SNAPSHOT-22Q1
4.1.0-SNAPSHOT-22Q2
...

Keeps lexicographical comparison but also embeds the intent of the release
and when it hit all in one bundle. And doesn't blow up our minor #'s and
lead to confusion.

~Josh

On Thu, Dec 16, 2021 at 10:03 AM Mick Semb Wever  wrote:

> 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
>
>

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps