On Thu, 18 May 2023 at 07:23, Benedict wrote:
> So we just rename alpha1 to beta1 if that happens?
>
Yes, agreed Benedict.
> 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 brows
> 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
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
...otherwise I'm fine w/ just the CEP name, like "CEP-7" for SAI, etc.
On Wed, May 17, 2023 at 11:24 PM Caleb Rackliffe
wrote:
> So when a CEP slips, do we have to create a 5.1-cep-N? Could we just have
> a version that's "NextMajorRelease" or something like that? It should still
> be pretty eas
So when a CEP slips, do we have to create a 5.1-cep-N? Could we just have a
version that's "NextMajorRelease" or something like that? It should still
be pretty easy to bulk replace if we have something else to filter on, like
belonging to an epic?
On Wed, May 17, 2023 at 6:42 PM Mick Semb Wever w
On Tue, 16 May 2023 at 13:02, J. D. Jordan
wrote:
> Process question/discussion. Should tickets that are merged to CEP feature
> branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have
> a fixver of 5.0 on them After merging to the feature branch?
>
>
> For the SAI CEP which i
I do not think we discussed it from feature branch perspective. (Happy to
stand corrected but I did not find anything in @dev archive myself) But we
do mark with 5.0 anything that lands in trunk. I think it might be a good
idea anything that lands in a feature branch to have different fix version
u
...but that and "What do we do with things that might be in 5.0 and might
not?" are different questions.
A version that denotes "next major release" until merged (at which point it
could be given a real version) could be helpful...
On Tue, May 16, 2023 at 3:28 PM Caleb Rackliffe
wrote:
> I like
I like the NA approach for sub-tasks that roll up to a parent/epic ticket.
When that lands, it gets a real version, and any sub-task is assumed to
also have that version.
Not that it has to be called "NA", but there should be something to denote
"inherits from parent".
On Tue, May 16, 2023 at 3:0
Copying my rely on the ticket…
We have this discussion roughly once per major. If you look back through dev@
you'll find the last one a few years back.
I don't recall NA ever being the approved approach, though. ".x" lines are
target versions, whereas concrete versions are the ones a fix landed
Process question/discussion. Should tickets that are merged to CEP feature
branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have a
fixver of 5.0 on them After merging to the feature branch?
For the SAI CEP which is also using the feature branch method the "reviewed and
mer
18 matches
Mail list logo
