e?
From: Konstantin Osipov
Date: Wednesday, 15 June 2022 at 20:56
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
* bened...@apache.org [22/06/15 18:38]:
> I expect LET to behave like SELECT, and I don’t expect this work to modify
> the behaviour of normal
> I agree a broader consensus beyond those on the jira ticket should be sought
> before committing the patch that bumps a new major.
Broader consensus should be sought on any ticket that breaks backwards
compatibility – even if we already have bumped major version.
A major version bump should
Osipov
Date: Wednesday, 15 June 2022 at 14:04
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
* bened...@apache.org [22/06/15 10:00]:
> It sounds like we’re zeroing in on a solution.
>
> To draw attention back to Jon’s email, I think the last open
+1
From: Blake Eggleston
Date: Tuesday, 14 June 2022 at 21:46
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
I'd lean towards 3, where the statement doesn't parse because `miles` is
ambiguous
On Jun 14, 2022, at 1:40 PM, bened...@apache.org<mailto:be
(or 3. Let schema updates break the statement – this might actually be
preferable, so long as it fails-fast rather than corrupts behaviour)
From: bened...@apache.org
Date: Tuesday, 14 June 2022 at 20:58
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
It sounds
, that was in reference to the "Would you require a LIMIT 1 clause if the
key did not fully specify a row?" question, so I think we're in agreement here.
Cheers,
Derek
On Tue, Jun 14, 2022 at 1:27 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>>
how we can start getting incremental
improvements into end users' hands more quickly, since the alternative right
now is to basically roll your own, right?
Cheers,
Derek
On Mon, Jun 13, 2022 at 4:16 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>>
o if...abort and commit if ... isn't popular.
On Jun 13, 2022, at 4:14 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
> Like I mentioned in my earlier email, the if/abort syntax throwing an
> exception would, at least as described, limit useful data returned to the
> clie
k we have evidence that it is fine to interpret NULL as “false” for the
evaluation of IF conditions.
Agree. Null == false isn't too much of a leap.
Thanks for taking up the charge on this one. Glad to see it moving forward!
Thanks,
Aaron
On Sun, Jun 12, 2022 at 10:33 AM
bened...@apa
10 WHERE ... AS car
COMMIT TRANSACTION
Cheers,
Derek
On Sun, Jun 12, 2022 at 5:34 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> I would love hearing from people on what they think.
^^ It would be great to have more participants in this conv
up the charge on this one. Glad to see it moving forward!
Thanks,
Aaron
On Sun, Jun 12, 2022 at 10:33 AM
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
Welcome Li, and thanks for your input
> When I first saw the syntax, I took it for gran
ight?!?! As if this needed to be more complex.
I think we have evidence that it is fine to interpret NULL as “false” for the
evaluation of IF conditions.
Agree. Null == false isn't too much of a leap.
Thanks for taking up the charge on this one. Glad to see it moving forward!
Thanks,
Aaron
I believe that is a MySQL specific concept. This is one problem with mimicking
SQL – it’s not one thing!
In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value
submitted to a Boolean operator yields UNKNOWN.
IF (X) THEN Y does not run Y if X is UNKNOWN;
IF (X) THEN Y
mitted multiple
times due to a connection time-out or other connectivity issue. I have no idea
how that is implemented under the hood and I don’t even know if this is
technically possible with the Accord design, but I thought it would be
interesting to think about.
Best regards,
Boxuan
On Jun
QL Example using JDBC: https://www.baeldung.com/java-jdbc-auto-commit)
Path 2)
Chart a new direction with new syntax
I genuinely don't have a clear answer, but I would love hearing from people on
what they think.
Patrick
On Fri, Jun 10, 2022 at 12:07 PM
bened...@apache.org<mailto:bened...@apache.o
to us
ultimately), but it feels like a nicer API for the user – depending on how
these exceptions are surfaced in client APIs.
From: bened...@apache.org
Date: Friday, 10 June 2022 at 19:59
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
So, thinking on it myself
... WHERE key=2;
ELSE
UPDATE ... SET ... WHERE key=3;
ENDIF
COMMIT TRANSACTION;
Which would make the proposed COMMIT IF we're talking about now a shorthand. Of
course this would be follow on work.
On Jun 8, 2022, at 1:20 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
I i
ermediate values would be straightforward to calculate though.
On Jun 6, 2022, at 4:33 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
It affects not just RETURNING but also conditions that are evaluated against
the row, and if we in future permit using the values from one select
: [DISCUSS] Change code style guide WRT to @Override in subclasses /
interface implementations
sounds good. Lazy consensus it is.
On Jun 4, 2022, at 11:09 AM, bened...@apache.org wrote:
I think lazy consensus is good enough here, since there has been no dissent so
far as I can tell. It’s easier
requested we return the post-update state of the cell.
On Jun 6, 2022, at 4:00 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
> if multiple updates end up touching the same cell, I’d expect the last one to
> win
Hmm, yes I suppose range tombstones are a plausible and reas
Thanks,
Blake
On Jun 6, 2022, at 9:41 AM, Henrik Ingo
mailto:henrik.i...@datastax.com>> wrote:
On Mon, Jun 6, 2022 at 5:28 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> One way to make it obvious is to require the user to explicitly
> One way to make it obvious is to require the user to explicitly type the
> SELECTs and then to require that all SELECTs appear before
> UPDATE/INSERT/DELETE.
Yes, I agree that SELECT statements should be required to go first.
However, I think this is sufficient and we can retain the shorter
?
I'll stop here for now.
Patrick
On Sat, Jun 4, 2022 at 3:34 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> The returned result set is after the updates are applied?
Returning the prior values is probably more powerful, as you can perform
un
> 1. Dependant SELECTs
> 2. Dependant UPDATEs
> 3. UPDATE from secondary index (or SASI)
> 5. UPDATE with predicate on non-primary key
So, I think these are all likely to be rejected the same way they are today, as
the individual statements would not parse [1,2] or be validated [3,5], as I’m
> The returned result set is after the updates are applied?
Returning the prior values is probably more powerful, as you can perform
unconditional updates and respond to the prior state, that you otherwise would
not know. It’s also simpler to implement.
My inclination is to require that SELECT
the guidance but I
think it’s in a good enough shape to publish.
On Jun 3, 2022, at 9:07 AM, bened...@apache.org wrote:
I always ask if we’re ready, get a few acks, then one or two new queries come
out of the woodwork.
Perhaps I will just publish, and we can start addressing these queries
: [DISCUSS] Change code style guide WRT to @Override in subclasses /
interface implementations
I don’t think the guide has yet been published to the official website, has it?
Maybe we should just get it out there.
On Jun 3, 2022, at 8:54 AM, bened...@apache.org wrote:
Somebody hasn’t looked
Somebody hasn’t looked at the new style guide*, the conversation for which
keeps rolling on and so it never quite gets promoted to the wiki. It says:
Always use @Override annotations when implementing abstract or interface
methods or overriding a parent method.
*
I’ve modified just the first sentence, to:
Dependencies expose the project to ongoing audit and maintenance burdens, and
security risks. We wish to minimise our declared and transitive dependencies
and to standardise mechanisms and solutions in the codebase. Adding new
dependencies requires
ke to have it explicitly stated.
Regards
On Tue, 31 May 2022 at 14:46, bened...@apache.org wrote:
>
> I think that it is hard to define what the right extent of a patch is, but it
> should be the minimal scope that the author feels sufficient to safely
> address the concerns of the patch. I
and they may exist since
early versions for example.
Best regards,
Ekaterina
On Mon, 30 May 2022 at 14:10, Derek Chen-Becker
mailto:de...@chen-becker.org>> wrote:
Looks great!
On Mon, May 30, 2022, 5:37 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>&g
Any more feedback around this? Everyone happy with the latest proposal?
From: bened...@apache.org
Date: Sunday, 15 May 2022 at 15:08
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I agree with this sentiment, but I think it will require a bit of time
I agree with this sentiment, but I think it will require a bit of time to
figure out where that balance is.
I’ve inserted a mention of @Nullable, @ThreadSafe, @NotThreadSafe and
@Immutable.
> If we only use one of the two - for example @Nullable - that leaves us with
> "We know the original
:45
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
On Sat, May 14, 2022 at 8:24 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> I'm in favor of codifying the usage of @NotNull and @Nullable stylist
if we uniformly used braces everywhere, but it does
look like there are quite a few places in the code where we have unbraced ifs
Overall the doc is well written and carefully considered, and I appreciate all
of the work that went into it!
Cheers,
Derek
From: "bened...@
to the wiki.
From: bened...@apache.org
Date: Monday, 14 March 2022 at 09:41
To: dev@cassandra.apache.org
Subject: Updating our Code Contribution/Style Guide
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well
I think this is close to what we settled on last we hashed this out.
From: Josh McKenzie
Date: Monday, 9 May 2022 at 22:47
To: dev@cassandra.apache.org
Subject: Re: How we flag tickets as blockers during freeze
As you mentioned on slack, we can introduce FixVersions for the unreleased
interim
are concerns about it.
Em qua., 27 de abr. de 2022 às 14:51,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future, which wo
One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future, which would be a breaking change.
This identifier will likely be used by Accord for correctness, too, and doing
something wrong with it could have severe consequences, so at
The property you are setting permits some kinds of privilege escalation, but by
default classes outside of those pre-defined by the whitelist are not
permitted. This is imposed here:
I just did the same for cassandra-accord, I guess some config was lost in the
upgrade
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-23074
From: Mick Semb Wever
Date: Monday, 4 April 2022 at 08:55
To: dev@cassandra.apache.org
Subject: Re: [GitHub] [cassandra-website] ossarga
to get up to speed with
writing in-jvm dtests and extending the framework.
Em ter., 29 de mar. de 2022 às 20:09,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
It often does not work. I can attest to many wasted weeks, on some environments
never
>>> without being caught by tests.
>>>
>>> Is there any way we could avoid duplicating functionality on the test
>>> server and use the same initialization code on in-jvm dtests?
>>>
>>> [1] -
>>> https://github.com/apache/
but I suspect we can get this in in April some time.
On Mon, Mar 14, 2022, at 8:36 AM,
bened...@apache.org<mailto:bened...@apache.org> wrote:
This is the limitation I mentioned. I think this is solely a question of
supplying an initial config that uses vnodes, i.e. that specifies
should also be specifying spacing for loop
guards, conditions, casts, etc?
From: bened...@apache.org
Date: Sunday, 20 March 2022 at 21:37
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
> We are talking about one extra line, not a dozen or more.
I think
> We are talking about one extra line, not a dozen or more.
I think you are confused about the context. The case I was discussing often
means 10+ additional lines at each call-site.
> Once the code gets more real, it is faster to read the difference between (a)
> and (c)
This isn’t a great
> I support this too… leads to more noise in, and less readability of, the
> patch.
Readability of the patch is not harmed with modern tooling (with whitespace
being highlighted differently to content changes).
Legibility of the code (not patch) should always be preferred IMO. To aid code
+1, let’s change our merge strategy
From: Josh McKenzie
Date: Wednesday, 16 March 2022 at 12:47
To: dev@cassandra.apache.org
Subject: Re: Using labels on pull requests in GitHub
I think the fact that they pile up is because our merge strategy means we don't
actually merge using the PR's we
Since PRs are a second class citizen to Jira, mostly used for a scratch pad for
nits and questions with code context, I suspect any improvements here will need
to be automated to have any hope of success.
From: Stefan Miklosovic
Date: Wednesday, 16 March 2022 at 08:16
To:
+1
From: Erick Ramirez
Date: Tuesday, 15 March 2022 at 22:08
To: dev@cassandra.apache.org
Subject: Re: [FOR REVIEW] Blog post: An Interview with Project Contributor,
Lorina Poland
Looks good to me!
On Wed, 16 Mar 2022 at 08:17, Chris Thornett
mailto:ch...@constantia.io>> wrote:
As
:52 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
I’m a strong -1 on strictly enforcing any style guide. It is there to help
shape contributions, review feedback and responding to said feedback. It can
also be used to setup IntelliJ’s code formatter to configure defaul
that the current codebase is not consistent since
it was written over a long period of time so it tends to confuse folks who are
working in different parts of the codebase. So this style guide would be very
helpful.
On Mar 14, 2022, at 2:41 AM, bened...@apache.org<mailto:bened...@apache.org>
d to move to the previous line, but sometimes it makes the
line much too long due to some nested calls or something else.
On Mon, Mar 14, 2022 at 4:02 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
Hi Jacek,
> Sometimes, althou
on if we should avoid making
method parameters and local variables `final` - this is inconsistent over the
code base, but I'd prefer not having them. If the method is large enough that
we might mistakenly reuse parameters/variables, we should probably refactor the
method.
/Marcus
On Mon, Mar 14, 2022 at 09:41
limitation.
On Mon, 14 Mar 2022 at 12:24, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
I am strongly in favour of deprecating python dtests in all cases where they
are currently superseded by in-jvm dtests. They are environmentally more
challen
I am strongly in favour of deprecating python dtests in all cases where they
are currently superseded by in-jvm dtests. They are environmentally more
challenging to work with, causing many problems on local and remote machines.
They are harder to debug, slower, flakier, and mostly less
+, bened...@apache.org wrote:
> Our style guide hasn’t been updated in about a decade, and I think it is
> overdue some improvements that address some shortcomings as well as modern
> facilities such as streams and lambdas.
>
> Most of this was put together for an effort Dines
uot; style check shows many existing issues in the Python
code, including libraries imported but unused, redefinition of unused imports
and invalid escape sequence in strings.
On 14/03/2022 09:41, bened...@apache.org<mailto:bened...@apache.org> wrote:
Our style guide hasn’t been updated i
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well as modern
facilities such as streams and lambdas.
Most of this was put together for an effort Dinesh started a few years ago, but
has languished since, in
At the very least we should wait until the current issues with CI have
resolved, so that pending work can merge, before declaring any freeze.
From: Mick Semb Wever
Date: Tuesday, 8 March 2022 at 15:13
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Next release cut
Should we plan some
I agree that a new configuration layout should be introduced once only, not
incrementally.
However, I disagree that we should immediately deprecate the old config file
and refuse to parse it. We can maintain compatibility indefinitely at low cost,
so we should do so.
Users of the old format,
starting to use it in our new tests and build our knowledge of
Harry. Regarding a migration of existing tests to it, I would wait a bit before
choosing to go down that path.
Le mer. 16 févr. 2022 à 16:30, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org&
build our knowledge of
> Harry. Regarding a migration of existing tests to it, I would wait a bit
> before choosing to go down that path.
>
>
>
> Le mer. 16 févr. 2022 à 16:30, bened...@apache.org a
> écrit :
>>
>> +1
>>
>>
>>
>> Th
+1
The Simulator is hopefully going to be another powerful tool for this kind of
work, and we should be encouraging the use of both for large or complex pieces
of work.
From: Alex Petrov
Date: Wednesday, 16 February 2022 at 11:56
To: dev@cassandra.apache.org
Subject: Re: Apache Cassandra
+1
From: Branimir Lambov
Date: Wednesday, 16 February 2022 at 08:58
To: dev@cassandra.apache.org
Subject: [VOTE] CEP-19: Trie memtable implementation
Hi everyone,
I'd like to propose CEP-19 for approval.
Proposal:
One issue with this approach is that we are advertising that we are preparing a
security release by preparing such a release candidate.
I wonder if we need to find a way to produce binaries without leaving an
obvious public mark (i.e. private CI, private branch)
From: Josh McKenzie
Date:
As discussed on 15234, there is never a rush to remove Config parameters, and
it should only be done when there’s some clear value. Since the overhead of
having an unused parameter is ~zero, in my opinion this occurs only when we
really need the operator to consider the semantic impact of its
> Is there some mechanism such as experimental flags, which would allow the
> SAI-only OR support to be merged into trunk
FWIW, I’m OK with this merging to trunk, either hidden behind a CI-only flag or
exposed to the user via some experimental flag (and a suitable NEWS.txt). We’ve
discussed
Why not have some default templates that can be specified by the schema without
touching the yaml, but overridden in the yaml as necessary?
From: Branimir Lambov
Date: Wednesday, 9 February 2022 at 09:35
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-19: Trie memtable implementation
FWIW, I think the proposed approach to configuration is fine.
I think selecting a choice for the user should be done simply and
deterministically. We should probably default to Trie based memtables for users
with a fresh config file, and we can consider changing the default in a later
release
I don’t have a strong opinion about CEP-7 taking a hard dependency on any new
CQL CEP, particularly from a point of view of first landing in the codebase.
From: Henrik Ingo
Date: Monday, 7 February 2022 at 12:03
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-7 Storage Attached Index
...@gmail.com>> wrote:
On Thu, Feb 3, 2022 at 7:19 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> It pretends to be Maven for dependency management, but this is a small part
> of the job of a build file.
It doesn't pretend, it actuall
, 2022 at 3:23 AM bened...@apache.org wrote:
> If we’re struggling to actually use ant how we want that’s another matter,
> but it’s easy to forget how much just works for us with ant
If you don't regularly work on the build system, it may be easy to
forget that ant works by actually
downsides
of adopting a new build tool, to allow the community to decide whether the
change is worth pursuing.
Em qui., 3 de fev. de 2022 às 07:28,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
> Aleksei has proven that he was able to deliver wor
rigger
another discussion about that.
Le jeu. 3 févr. 2022 à 10:17, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> a écrit :
I don’t have a super strong desire to stay with ant, I just have a desire not
to unduly burden the project with unnecessary churn. T
that it is the case.
Le jeu. 3 févr. 2022 à 09:32, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> a écrit :
I’m going to be a killjoy and once again query what value changing build system
brings, that outweighs the disruption to current long-term contributo
I’m going to be a killjoy and once again query what value changing build system
brings, that outweighs the disruption to current long-term contributors that
can easily get things done today?
At the very least there should be a ranked choice vote that includes today’s
build system.
From:
powerful
tests that are also able to execute faster (for reasons of integration, not
language).
From: Brandon Williams
Date: Wednesday, 26 January 2022 at 16:09
To: dev
Subject: Re: Have we considered static type checking for our python libs?
On Wed, Jan 26, 2022 at 7:43 AM bened...@apache.org
debug failures much more easily.
Please Yes. If we can get away from python upgrade tests I think all our lives
would be improved.
I like it.
On Wed, Jan 26, 2022 at 8:42 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
We could set th
, however this is something someone would have to take on as
an effort and I don't believe I've seen anybody step up yet. At the current
rate we're going to be dragging along the python dtests into perpetuity.
On Wed, Jan 26, 2022 at 8:16 AM bened...@apache.org<mailto:bened...@apache.
I was sort of hoping we would retire the python dtests before long, at least in
large part (probably not ever entirely, but 99%).
I think many of them could be migrated to in-jvm dtests without much effort. I
would hate to expend loads of effort modernising them when the same effort
could see
-4.0 .
git commit
From: bened...@apache.org
Date: Wednesday, 5 January 2022 at 21:07
To: Mick Semb Wever
Cc: dev
Subject: Re: [DISCUSS] Releasable trunk and quality
> If you see a merge commit in the history, isn't it normal to presume that it
> will contain the additional
t we don't forget to apply something to all branches
+(?) Is the devil we know
That's a lot of negatives for a very fixable single positive and some FUD.
On Tue, Jan 4, 2022 at 7:01 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
To answer yo
> If you see a merge commit in the history, isn't it normal to presume that it
> will contain the additional change for that branch for the parent commit
> getting merged in?
Sure, but it is exceptionally non-trivial to treat the work as a single diff in
any standard UX. In practice it
is headache enough when it goes wrong).
From: bened...@apache.org
Date: Tuesday, 4 January 2022 at 23:52
To: David Capwell , Joshua McKenzie
Cc: Henrik Ingo , dev
Subject: Re: [DISCUSS] Releasable trunk and quality
That all sounds terribly complicated to me.
My view is that we should switch
That all sounds terribly complicated to me.
My view is that we should switch to the branch strategy outlined by Henrik (I
happen to prefer it anyway) and move to GitHub integrations to control merge
for each branch independently. Simples.
From: David Capwell
Date: Tuesday, 4 January 2022 at
> You were part of that slack thread, so it was a bad presumption on my behalf.
I am flattered, but I’m sure your intention was in fact to involve everyone in
this discussion. As it happens, I commented only on the end of that lengthy
thread and did not participate in the section you linked, so
> 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 wasted a
> 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
>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
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’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
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
> 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
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
> 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
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 Sem
> 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
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
> 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
1 - 100 of 256 matches
Mail list logo
