k this problem you raise is a concern, even
>> with this recently introduced faulty implementation of Semver. A2 is zero
>> cost to implement, but even A1 would be fine without any work. It is
>> unlikely we would ever need to compare a -pre version to -alpha or any
>&
s since we will have no users deploying them.
>
>
>
>
>
> *From: *Mick Semb Wever
> *Date: *Wednesday, 22 December 2021 at 16:02
> *To: *
> *Cc: *dev@cassandra.apache.org
> *Subject: *Re: [DISCUSS] Periodic snapshot publishing with minor version
> bumps
>
>
g them.
From: Mick Semb Wever
Date: Wednesday, 22 December 2021 at 16:02
To:
Cc: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> > Yeah, not described enough in this thread, it is part of the motivation to
> > the proposal
>
> > Yeah, not described enough in this thread, it is part of the motivation to
> > the proposal
>
> I don’t believe it has been mentioned once in this thread. This should have
> been clearly stated upfront as a motivation. Thus far no positive case has
> been made on this topic, we have instead
unnecessary Semver dependency
introduced at the time that it was, creating unnecessary churn and
compatibility work to no apparent advantage.
From: Mick Semb Wever
Date: Wednesday, 22 December 2021 at 12:14
To:
Cc: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Periodic snapshot publishing
>
> Do you intend to use this capability, and if so could you point out where you
> highlighted this motivation previously?
>
Yeah, not described enough in this thread, it is part of the motivation
to the proposal, and was discussed in the slack thread:
https://the-asf.slack.com/archives/CK23J
apshot 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
on (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 furth
> (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 :-)
: [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
> 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
ha1
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
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 fine
> 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
cisely 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 he
> "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
(All the break&fix that goes with it)
On Thu, 16 Dec 2021 at 19:19, bened...@apache.org
wrote:
> 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 snap
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
o: 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
>
> 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 suppor
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...@
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 dealbreake
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 un
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 als
for why this should not happen.
From: Joshua McKenzie
Date: Thursday, 16 December 2021 at 17:05
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
>
> it breaks the code and drivers.
b) accepting that the code and drivers is fragile with v
pache.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: [DIS
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 com
> >
> > 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 res
;
> 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 p
>
> I don’t really see the advantage to this over 4.1.0-SNAPSHOT1
Only benefit is that it indicates the purpose of the snapshot (date-based)
rather than leaving it unspecified / as an exercise to the reader.
If the theorized workflow is people testing latest snapshot, doesn't add
any value.
On
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, an
>
> 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 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
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/p16389509613
41 matches
Mail list logo
