> 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 pu
>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 s
> (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 vers
> 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 ->
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 t
> 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 :-)
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,
> 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).
Currently our snapshots do *not* come with a pre-release label, but
they do come with a build metadata label (being either the expl
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 break
(I’ve taken this off list for now)
From: Bowen Song
Date: Tuesday, 21 December 2021 at 18:29
To: bened...@apache.org
Cc: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Disabling MIME-part filtering on this mailing list
Hmm, that's a bit unexpected.
Could you please have a look at the email h
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 the
> 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
Hmm, that's a bit unexpected.
Could you please have a look at the email headers and see what's the
reason for it being treated that way? Have a look at the
"Authentication-Results" headers, and the headers with "spam" in their
names, especially "X-Spam-Status" if it's present.
I suspect it w
Unfortunately it still arrived in my junk mail folder ☹
From: Bowen Song
Date: Tuesday, 21 December 2021 at 12:02
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Disabling MIME-part filtering on this mailing list
I have just received a confirmation from Infra informing me that this
change h
> 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
(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 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 rele
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
FWIW, I thought I could link to an example MongoDB commit:
https://github.com/mongodb/mongo/commit/dec388494b652488259072cf61fd987af3fa8470
* Fixes start from trunk or whatever is the highest version that includes
the bug
* It is then cherry picked to each stable version that needs to fix. Above
Hopefully it arrives in your inbox without trouble, and my email
> address no longer has the ".INVALID" append to it.
>
The .INVALID is no longer there.
Thanks for tackling this Bowen.
I have just received a confirmation from Infra informing me that this
change has been made. I'm sending this email as an update but also a
test. Hopefully it arrives in your inbox without trouble, and my email
address no longer has the ".INVALID" append to it.
On 04/12/2021 17:15, Bowen Song w
21 matches
Mail list logo
