> They stay on 5.0-target after close and move to 5.0.0 when the epic is merged
> and closes
Yep. When they merge to the feature branch they're still not on trunk (or
whatever release branch) so they're still targeting it.
That leaves us with the one indicative case: something with "resolution =
So what do we do with feature branch merged tickets in this model? They stay
on 5.0-target after close and move to 5.0.0 when the epic is merged and closes?
> On May 18, 2023, at 9:33 AM, Josh McKenzie wrote:
>
>> My mental model, though, is that anything that’s not a concrete release
>> numb
> My mental model, though, is that anything that’s not a concrete release
> number is a target version. Which is where 5.0 goes wrong - it’s not a
> release so it should be a target, but for some reason we use it as a
> placeholder to park work arriving in 5.0.0.
Ahhh.
> So tickets go t
The .x approach only breaks down for unreleased majors, for which all of our intuitions breakdown and we rehash it every year.My mental model, though, is that anything that’s not a concrete release number is a target version. Which is where 5.0 goes wrong - it’s not a release so it should be a targ
So we just rename alpha1 to beta1 if that happens?
Or, we point resolved tickets straight to 5.0.0, and add 5.0-alpha1 to any
tickets with *only* 5.0.0
This is probably the easiest for folk to understand when browsing.
Finding new features is easy either way - look for 5.0.0.
> On 18 May 2023,
> My personal view is that 5.0 should not be used for any resolved tickets -
> they should go to 5.0-alpha1, since this is the correct release for them. 5.0
> can then be the target version, which makes more sense given it isn’t a
> concrete release.
Well now you're just opening Pandora's box ab
So when a CEP slips, do we have to create a 5.1-cep-N?
>
No, you'd just rename it, easy to do in just one place.
I really don't care, but the version would at least helps indicate what the
branch is getting rebased off.
> My personal view is that 5.0 should not be used for any resolved ticket
Hi Maxim,
thanks for bringing this up. I am glad you did the heavy-lifting in / around
CassandraRelevantProperties and we can build on top of this.
I am fine with @Replaces for Cassandra system properties. After we put
everything into CassandraRelevantProperties, one can easily see that there a
I don’t think we should over complicate this with special CEP release targets. If we do, they shouldn’t be versioned.My personal view is that 5.0 should not be used for any resolved tickets - they should go to 5.0-alpha1, since this is the correct release for them. 5.0 can then be the target versio
CEP-N seems like a good compromise. NextMajorRelease bumps into our
interchangeable use of "Major" and "Minor" from a semver perspective and could
get confusing. Suppose we could do NextFeatureRelease, but at that point why
not just have it linked to the CEP and have the epic set.
On Thu, May 1
Hello everyone,
Thanks for following this thread and the review, all the system
properties have been moved to CassandraRelevantProperties.
So you can find out what it looks like from the following link:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/CassandraR
I don't want to hijack this thread, I just want to say that the point 4) seems
to be recurring. I second Caleb in saying that transactional metadata would
probably fix this. Because of the problem of not being sure that all config is
same, cluster-wide, I basically dropped the effort on CEP-24 b
12 matches
Mail list logo
