blem 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
>> other
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
>
>
m.
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:
> 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 sn
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
> 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
: [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
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
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
ate: 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 t
> 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
(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
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
> "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
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
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
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:
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 n
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
sfy 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 snaps
>
> 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
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
> >
> > 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
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
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,
>
> 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
35 matches
Mail list logo
