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
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 distin
> 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 fixi
>
> 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...@
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 De
>
>
> > ci-cassandra.a.o needs to be our canonical CI
>
> it's the only one fully usable by a volunteer based
>
>
> only green in both counts as green
>
> I think today might just be my day to annoy you Mick. :D Sorry!
>
On the day I'm laid up in bed with a cold.
Go for gold :-)
I think this is
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
>
> ci-cassandra.a.o needs to be our canonical CI
it's the only one fully usable by a volunteer based
only green in both counts as green
I think today might just be my day to annoy you Mick. :D Sorry!
I think this is contradictory. We can't require circle to be green for a
release if the free
> 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 a
> Oh yeah, that's a dealbreaker then. Wasn't aware.
Is this a dealbreaker? 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?
There is a significant downside to publishing snapshots with full versio
>
> 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 "periodi
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 stuf
> >
> > 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
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-S
>
> 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 we
>
> Mick, did I miss anything?
>
Yup, ci-cassandra.a.o needs to be our canonical CI because of the
reasons you state, and because it's the only one fully usable by a
volunteer based PMC, i.e. community donated hardware, controlled by
ASF, and no need for a proprietary licence.
I think we should
I've never used it, but that might not be a useful data point because
this isn't the sort of area I typically do work on, either. +0 :)
On Thu, Dec 16, 2021 at 8:45 AM Joshua McKenzie wrote:
>
> In tracking down the leak that led to
> https://issues.apache.org/jira/browse/CASSANDRA-17174, it came
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
In tracking down the leak that led to
https://issues.apache.org/jira/browse/CASSANDRA-17174, it came to my
attention that debugging ref counts is a -D property rather than a JMX
flippable hot property in Ref.java:
public static final boolean DEBUG_ENABLED =
> System.getProperty("cassandra.debugref
As far as I am aware Jenkins is the official CI running on Apache infra. It
preserves historical data and every committer and PMC member has access to
run all tests pre-commit. We have project builds after every commit.
My understanding about CircleCI - free tier is available to everyone but
not a
24 matches
Mail list logo
