Re: [DISCUSS] Feature branch version hygiene

[Mick Semb Wever]

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 browsing.
> Finding new features is easy either way - look for 5.0.0.
>


No opinion either way. I suspect 5.0 was used as the additional label
because 5.0.0 and other versions are the specific versions as found in
CHANGES.txt

Re: [DISCUSS] Feature branch version hygiene

[Josh McKenzie]

> 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 = Fixed 
AND FixVersion ~ 'target'" means it's on a feature branch. At time of feature 
branch merge folks will need to update the FixVersion on the epic + all child 
tickets that are merged onto that branch.

On Thu, May 18, 2023, at 11:11 AM, Jeremiah D Jordan wrote:
> 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 
>>> 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 to 5.0-target if they target 5.0, and to 5.0.0 once they are 
>>> resolved (with additional labels as necessary)
>> Adding -target would definitely make things more clear. If we moved to "5.0 
>> == unreleased, always move to something on commit" then you still have to 
>> find some external source to figure out what's going on w/our versioning.
>> 
>> I like 5.0-target. Easy to query for "FixVersion = 5.0-target AND type != 
>> 'Bug'" to find stragglers after GA is cut to move to 5.1-target.
>> 
>> Still have the "update children FixVersion for feature branch when branch is 
>> merged" bit but that's not so onerous.
>> 
>> On Thu, May 18, 2023, at 10:28 AM, Benedict wrote:
>>> 
>>> 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 target, but for some reason we use it as a 
>>> placeholder to park work arriving in 5.0.0.
>>> 
>>> If we instead use 5.0.0 for this purpose, we just need to get 5.0-alpha1 
>>> labels added when those releases are cut.
>>> 
>>> Then I propose we break the confusion in both directions by scrapping 5.0 
>>> entirely and introducing 5.0-target.
>>> 
>>> So tickets go to 5.0-target if they target 5.0, and to 5.0.0 once they are 
>>> resolved (with additional labels as necessary)
>>> 
>>> Simples?
>>> 
 On 18 May 2023, at 15:21, Josh McKenzie  wrote:
 
> 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 about our strange idioms with 
 FixVersion usage. ;)
 
> every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty 
> clear what this means.
 I think this diverges from our current paradigm where "5.x" == next 
 feature release, "5.0.x" == next patch release (i.e. bugfix only). Not to 
 say it's bad, just an adjustment... which if we're open to adjustment...
 
 I'm receptive to transitioning the discussion to that either on this 
 thread or another; IMO we remain in a strange and convoluted place with 
 our FixVersioning. My understanding of our current practice:
  • .x is used to denote target version. For example: 5.x, 5.0.x, 5.1.x, 
 4.1.x
  • When a ticket is committed, the FixVersion is transitioned to resolve 
 the X to the next unreleased version in which it'll release
  • Weird Things are done to make this work for the release process and 
 release manager on feature releases (alpha, beta, etc)
  • There's no clear fit for feature branch tickets in the above schema
 
 And if I take what I think you're proposing here and extrapolate it out:
  • .0 is used to denote target version. For example: 5.0. 5.0.0. 5.1.0. 
 4.1.0
  • This appears to break down for patch releases: we _do_ release .0 
 versions of them rather than alpha/beta/etc, so a ticket targeting 4.1.0 
 would initially mean 2 different things based on resolved vs. unresolved 
 status (resolved == in release, unresolved == targeting next unreleased) 
 and that distinction would disappear on resolution (i.e. resolved + 4.1.0 
 would no longer definitively mean "contained in .0 release")
  • When a release is cut, we bulk update FixVersion ending in .0 to the 
 release version in which they're contained (not clear how to disambiguate 
 the things from the above bullet point)
  • For feature releases, .0 will transition to -alpha1
 One possible 

Re: [DISCUSS] Feature branch version hygiene

[Jeremiah D Jordan]

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 
>> 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 to 5.0-target if they target 5.0, and to 5.0.0 once they are 
>> resolved (with additional labels as necessary)
> Adding -target would definitely make things more clear. If we moved to "5.0 
> == unreleased, always move to something on commit" then you still have to 
> find some external source to figure out what's going on w/our versioning.
> 
> I like 5.0-target. Easy to query for "FixVersion = 5.0-target AND type != 
> 'Bug'" to find stragglers after GA is cut to move to 5.1-target.
> 
> Still have the "update children FixVersion for feature branch when branch is 
> merged" bit but that's not so onerous.
> 
> On Thu, May 18, 2023, at 10:28 AM, Benedict wrote:
>> 
>> 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 target, but for some reason we use it as a 
>> placeholder to park work arriving in 5.0.0.
>> 
>> If we instead use 5.0.0 for this purpose, we just need to get 5.0-alpha1 
>> labels added when those releases are cut.
>> 
>> Then I propose we break the confusion in both directions by scrapping 5.0 
>> entirely and introducing 5.0-target.
>> 
>> So tickets go to 5.0-target if they target 5.0, and to 5.0.0 once they are 
>> resolved (with additional labels as necessary)
>> 
>> Simples?
>> 
>>> On 18 May 2023, at 15:21, Josh McKenzie  wrote:
>>> 
 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 about our strange idioms with 
>>> FixVersion usage. ;)
>>> 
 every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty 
 clear what this means.
>>> I think this diverges from our current paradigm where "5.x" == next feature 
>>> release, "5.0.x" == next patch release (i.e. bugfix only). Not to say it's 
>>> bad, just an adjustment... which if we're open to adjustment...
>>> 
>>> I'm receptive to transitioning the discussion to that either on this thread 
>>> or another; IMO we remain in a strange and convoluted place with our 
>>> FixVersioning. My understanding of our current practice:
>>> .x is used to denote target version. For example: 5.x, 5.0.x, 5.1.x, 4.1.x
>>> When a ticket is committed, the FixVersion is transitioned to resolve the X 
>>> to the next unreleased version in which it'll release
>>> Weird Things are done to make this work for the release process and release 
>>> manager on feature releases (alpha, beta, etc)
>>> There's no clear fit for feature branch tickets in the above schema
>>> 
>>> And if I take what I think you're proposing here and extrapolate it out:
>>> .0 is used to denote target version. For example: 5.0. 5.0.0. 5.1.0. 4.1.0
>>> This appears to break down for patch releases: we _do_ release .0 versions 
>>> of them rather than alpha/beta/etc, so a ticket targeting 4.1.0 would 
>>> initially mean 2 different things based on resolved vs. unresolved status 
>>> (resolved == in release, unresolved == targeting next unreleased) and that 
>>> distinction would disappear on resolution (i.e. resolved + 4.1.0 would no 
>>> longer definitively mean "contained in .0 release")
>>> When a release is cut, we bulk update FixVersion ending in .0 to the 
>>> release version in which they're contained (not clear how to disambiguate 
>>> the things from the above bullet point)
>>> For feature releases, .0 will transition to -alpha1
>>> One possible solution would be to just no longer release a .0 version of 
>>> things and reserve .0 to indicate "parked". I don't particularly like that 
>>> but it's not the worst.
>>> 
>>> Another possible solution would be to just scrap this approach entirely and 
>>> go with:
>>> FixVersion on unreleased _and still advocated for tickets_ always targets 
>>> the next unreleased version. For other tickets where nobody is advocating 
>>> for their work / inclusion, we either FixVersion "Backlog" or close as 
>>> "Later"
>>> When a release is cut, roll all unresolved tickets w/that FixVersion to the 
>>> next unreleased FixVersion
>>> When we're gearing up to a release, we can do a broad pass on 

Re: [DISCUSS] Feature branch version hygiene

[Josh McKenzie]

> 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 to 5.0-target if they target 5.0, and to 5.0.0 once they are 
> resolved (with additional labels as necessary)
Adding -target would definitely make things more clear. If we moved to "5.0 == 
unreleased, always move to something on commit" then you still have to find 
some external source to figure out what's going on w/our versioning.

I like 5.0-target. Easy to query for "FixVersion = 5.0-target AND type != 
'Bug'" to find stragglers after GA is cut to move to 5.1-target.

Still have the "update children FixVersion for feature branch when branch is 
merged" bit but that's not so onerous.

On Thu, May 18, 2023, at 10:28 AM, Benedict wrote:
> 
> 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 target, but for some reason we use it as a 
> placeholder to park work arriving in 5.0.0.
> 
> If we instead use 5.0.0 for this purpose, we just need to get 5.0-alpha1 
> labels added when those releases are cut.
> 
> Then I propose we break the confusion in both directions by scrapping 5.0 
> entirely and introducing 5.0-target.
> 
> So tickets go to 5.0-target if they target 5.0, and to 5.0.0 once they are 
> resolved (with additional labels as necessary)
> 
> Simples?
> 
>> On 18 May 2023, at 15:21, Josh McKenzie  wrote:
>> 
>>> 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 about our strange idioms with 
>> FixVersion usage. ;)
>> 
>>> every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty 
>>> clear what this means.
>> I think this diverges from our current paradigm where "5.x" == next feature 
>> release, "5.0.x" == next patch release (i.e. bugfix only). Not to say it's 
>> bad, just an adjustment... which if we're open to adjustment...
>> 
>> I'm receptive to transitioning the discussion to that either on this thread 
>> or another; IMO we remain in a strange and convoluted place with our 
>> FixVersioning. My understanding of our current practice:
>>  • .x is used to denote target version. For example: 5.x, 5.0.x, 5.1.x, 4.1.x
>>  • When a ticket is committed, the FixVersion is transitioned to resolve the 
>> X to the next unreleased version in which it'll release
>>  • Weird Things are done to make this work for the release process and 
>> release manager on feature releases (alpha, beta, etc)
>>  • There's no clear fit for feature branch tickets in the above schema
>> 
>> And if I take what I think you're proposing here and extrapolate it out:
>>  • .0 is used to denote target version. For example: 5.0. 5.0.0. 5.1.0. 4.1.0
>>  • This appears to break down for patch releases: we _do_ release .0 
>> versions of them rather than alpha/beta/etc, so a ticket targeting 4.1.0 
>> would initially mean 2 different things based on resolved vs. unresolved 
>> status (resolved == in release, unresolved == targeting next unreleased) and 
>> that distinction would disappear on resolution (i.e. resolved + 4.1.0 would 
>> no longer definitively mean "contained in .0 release")
>>  • When a release is cut, we bulk update FixVersion ending in .0 to the 
>> release version in which they're contained (not clear how to disambiguate 
>> the things from the above bullet point)
>>  • For feature releases, .0 will transition to -alpha1
>> One possible solution would be to just no longer release a .0 version of 
>> things and reserve .0 to indicate "parked". I don't particularly like that 
>> but it's not the worst.
>> 
>> Another possible solution would be to just scrap this approach entirely and 
>> go with:
>>  • FixVersion on unreleased _and still advocated for tickets_ always targets 
>> the next unreleased version. For other tickets where nobody is advocating 
>> for their work / inclusion, we either FixVersion "Backlog" or close as 
>> "Later"
>>  • When a release is cut, roll all unresolved tickets w/that FixVersion to 
>> the next unreleased FixVersion
>>  • When we're gearing up to a release, we can do a broad pass on everything 
>> that's unreleased w/the next feature releases FixVersion and move tickets 
>> that are desirable but not blockers to the next unreleased FixVersion (patch 
>> for bug, minor/major for improvements or new features)
>>  • CEP tickets target the same FixVersion (i.e. next 

Re: [DISCUSS] Feature branch version hygiene

[Benedict]

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 target, but for some reason we use it as a placeholder to park work arriving in 5.0.0.If we instead use 5.0.0 for this purpose, we just need to get 5.0-alpha1 labels added when those releases are cut.Then I propose we break the confusion in both directions by scrapping 5.0 entirely and introducing 5.0-target.So tickets go to 5.0-target if they target 5.0, and to 5.0.0 once they are resolved (with additional labels as necessary)Simples?On 18 May 2023, at 15:21, Josh McKenzie  wrote: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 about our strange idioms with FixVersion usage. ;)every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty clear what this means.I think this diverges from our current paradigm where "5.x" == next feature release, "5.0.x" == next patch release (i.e. bugfix only). Not to say it's bad, just an adjustment... which if we're open to adjustment...I'm receptive to transitioning the discussion to that either on this thread or another; IMO we remain in a strange and convoluted place with our FixVersioning. My understanding of our current practice:.x is used to denote target version. For example: 5.x, 5.0.x, 5.1.x, 4.1.xWhen a ticket is committed, the FixVersion is transitioned to resolve the X to the next unreleased version in which it'll releaseWeird Things are done to make this work for the release process and release manager on feature releases (alpha, beta, etc)There's no clear fit for feature branch tickets in the above schemaAnd if I take what I think you're proposing here and extrapolate it out:.0 is used to denote target version. For example: 5.0. 5.0.0. 5.1.0. 4.1.0This appears to break down for patch releases: we _do_ release .0 versions of them rather than alpha/beta/etc, so a ticket targeting 4.1.0 would initially mean 2 different things based on resolved vs. unresolved status (resolved == in release, unresolved == targeting next unreleased) and that distinction would disappear on resolution (i.e. resolved + 4.1.0 would no longer definitively mean "contained in .0 release")When a release is cut, we bulk update FixVersion ending in .0 to the release version in which they're contained (not clear how to disambiguate the things from the above bullet point)For feature releases, .0 will transition to -alpha1One possible solution would be to just no longer release a .0 version of things and reserve .0 to indicate "parked". I don't particularly like that but it's not the worst.Another possible solution would be to just scrap this approach entirely and go with:FixVersion on unreleased _and still advocated for tickets_ always targets the next unreleased version. For other tickets where nobody is advocating for their work / inclusion, we either FixVersion "Backlog" or close as "Later"When a release is cut, roll all unresolved tickets w/that FixVersion to the next unreleased FixVersionWhen we're gearing up to a release, we can do a broad pass on everything that's unreleased w/the next feature releases FixVersion and move tickets that are desirable but not blockers to the next unreleased FixVersion (patch for bug, minor/major for improvements or new features)CEP tickets target the same FixVersion (i.e. next unreleased Feature release) as their parents. When the parent epic gets a new FixVersion on resolution, all children get that FixVersion (i.e. when we merge the CEP and update its FixVersion, we bulk update all children tickets)On Thu, May 18, 2023, at 9:08 AM, Benedict wrote: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 version, which makes more sense given it isn’t a concrete release.But, in lieu of that, every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty clear what this means. Some tickets that don’t hit 5.0.0 can then be postponed to a later version, but it’s not like this is burdensome. Anything marked feature/improvement and 5.0.x gets bumped to 5.1.x.On 18 May 2023, at 13:58, Josh McKenzie  wrote: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 

Re: [DISCUSS] Feature branch version hygiene

[Benedict]

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, at 15:08, Mick Semb Wever  wrote:
> 
> 
> 
> 
>> 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 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.
> 
> 
> Each time, we don't know if the first release will be an alpha1 or if we're 
> confident enough to go straight to a beta1.
> A goal with stable trunk would make the latter possible.
> 
> And with the additional 5.0 label has been requested by a few to make it easy 
> to search for what's new, this has been the simplest way.
> 

Re: [DISCUSS] Feature branch version hygiene

[Josh McKenzie]

> 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 about our strange idioms with 
FixVersion usage. ;)

> every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty 
> clear what this means.
I think this diverges from our current paradigm where "5.x" == next feature 
release, "5.0.x" == next patch release (i.e. bugfix only). Not to say it's bad, 
just an adjustment... which if we're open to adjustment...

I'm receptive to transitioning the discussion to that either on this thread or 
another; IMO we remain in a strange and convoluted place with our 
FixVersioning. My understanding of our current practice:
 • .x is used to denote target version. For example: 5.x, 5.0.x, 5.1.x, 4.1.x
 • When a ticket is committed, the FixVersion is transitioned to resolve the X 
to the next unreleased version in which it'll release
 • Weird Things are done to make this work for the release process and release 
manager on feature releases (alpha, beta, etc)
 • There's no clear fit for feature branch tickets in the above schema

And if I take what I think you're proposing here and extrapolate it out:
 • .0 is used to denote target version. For example: 5.0. 5.0.0. 5.1.0. 4.1.0
 • This appears to break down for patch releases: we _do_ release .0 versions 
of them rather than alpha/beta/etc, so a ticket targeting 4.1.0 would initially 
mean 2 different things based on resolved vs. unresolved status (resolved == in 
release, unresolved == targeting next unreleased) and that distinction would 
disappear on resolution (i.e. resolved + 4.1.0 would no longer definitively 
mean "contained in .0 release")
 • When a release is cut, we bulk update FixVersion ending in .0 to the release 
version in which they're contained (not clear how to disambiguate the things 
from the above bullet point)
 • For feature releases, .0 will transition to -alpha1
One possible solution would be to just no longer release a .0 version of things 
and reserve .0 to indicate "parked". I don't particularly like that but it's 
not the worst.

Another possible solution would be to just scrap this approach entirely and go 
with:
 • FixVersion on unreleased _and still advocated for tickets_ always targets 
the next unreleased version. For other tickets where nobody is advocating for 
their work / inclusion, we either FixVersion "Backlog" or close as "Later"
 • When a release is cut, roll all unresolved tickets w/that FixVersion to the 
next unreleased FixVersion
 • When we're gearing up to a release, we can do a broad pass on everything 
that's unreleased w/the next feature releases FixVersion and move tickets that 
are desirable but not blockers to the next unreleased FixVersion (patch for 
bug, minor/major for improvements or new features)
 • CEP tickets target the same FixVersion (i.e. next unreleased Feature 
release) as their parents. When the parent epic gets a new FixVersion on 
resolution, all children get that FixVersion (i.e. when we merge the CEP and 
update its FixVersion, we bulk update all children tickets)

On Thu, May 18, 2023, at 9:08 AM, Benedict wrote:
> 
> 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 version, which makes more sense given it isn’t a 
> concrete release.
> 
> But, in lieu of that, every ticket targeting 5.0 could use fixVersion 5.0.x, 
> since it is pretty clear what this means. Some tickets that don’t hit 5.0.0 
> can then be postponed to a later version, but it’s not like this is 
> burdensome. Anything marked feature/improvement and 5.0.x gets bumped to 
> 5.1.x.
> 
> 
> 
> 
> 
> 
>> On 18 May 2023, at 13:58, Josh McKenzie  wrote:
>> 
>> 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 18, 2023, at 12:26 AM, Caleb Rackliffe wrote:
>>> ...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 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  wrote:
> 
> 
> On Tue, 16 May 2023 at 13:02, 

Re: [DISCUSS] Feature branch version hygiene

[Mick Semb Wever]

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 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.
>


Each time, we don't know if the first release will be an alpha1 or if we're
confident enough to go straight to a beta1.
A goal with stable trunk would make the latter possible.

And with the additional 5.0 label has been requested by a few to make it
easy to search for what's new, this has been the simplest way.

Re: [DISCUSS] Feature branch version hygiene

[Benedict]

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 version, which makes more sense given it isn’t a concrete release.But, in lieu of that, every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty clear what this means. Some tickets that don’t hit 5.0.0 can then be postponed to a later version, but it’s not like this is burdensome. Anything marked feature/improvement and 5.0.x gets bumped to 5.1.x.On 18 May 2023, at 13:58, Josh McKenzie  wrote: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 18, 2023, at 12:26 AM, Caleb Rackliffe wrote:...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 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  wrote: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 is also using the feature branch method the "reviewed and merged to feature branch" tickets seem to be given a version of NA.Not sure that's the best “waiting for cep to merge” version either?  But it seems better than putting 5.0 on them to me.Why I’m not keen on 5.0 is because if we cut the release today those tickets would not be there.What do other people think?  Is there a better version designation we can use?On a different project I have in the past made a “version number” in JIRA for each long running feature branch. Tickets merged to the feature branch got the epic ticket number as their version, and then it got updated to the “real” version when the feature branch was merged to trunk.Thanks for raising the thread, I remember there was some confusion early wrt features branches too.To rehash, for everything currently resolved in trunk 5.0 is the correct fixVersion.  (And there should be no unresolved issues today with 5.0 fixVersion, they should be 5.x)When alpha1 is cut, then the 5.0-alpha1 fixVersion is created and everything with 5.0 also gets  5.0-alpha1.  At the same time 5.0-alpha2, 5.0-beta, 5.0-rc, 5.0.0 fixVersions are created.  Here both 5.0-beta and 5.0-rc are blocking placeholder fixVersions: no resolved issues are left with this fixVersion the same as the .x placeholder fixVersions. The 5.0.0 is also used as a blocking version, though it is also an eventual fixVersion for resolved tickets.  Also note, all tickets up to and including 5.0.0 will also have the 5.0 fixVersion.A particular reason for doing things the way they are is to make it easy for the release manager to bulk correct fixVersions, at release time or even later, i.e. without having to read the ticket or go talk to authors or painstakingly crawl CHANGES.txt.For feature branches my suggestion is that we create a fixVersion for each of them, e.g. 5.0-cep-15Yup, that's your suggestion Jeremiah (I wrote this up on the plane before I got to read your post properly).(As you say) This then makes it easy to see where the code is (or what the patch is currently being based on). And when the feature branch is merged then it is easy to bulk replace it with trunk's fixVersion, e.g.  5.0-cep-15 with 5.0The NA fixVersion was introduced for the other repositories, e.g. website updates.

Re: [DISCUSS] Feature branch version hygiene

[Josh McKenzie]

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 18, 2023, at 12:26 AM, Caleb Rackliffe wrote:
> ...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 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  wrote:
>>> 
>>> 
>>> 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 is also using the feature branch method the 
 "reviewed and merged to feature branch" tickets seem to be given a version 
 of NA.
 
 
 
 Not sure that's the best “waiting for cep to merge” version either?  But 
 it seems better than putting 5.0 on them to me.
 
 
 
 Why I’m not keen on 5.0 is because if we cut the release today those 
 tickets would not be there.
 
 
 
 What do other people think?  Is there a better version designation we can 
 use?
 
 
 
 On a different project I have in the past made a “version number” in JIRA 
 for each long running feature branch. Tickets merged to the feature branch 
 got the epic ticket number as their version, and then it got updated to 
 the “real” version when the feature branch was merged to trunk.
 
>>> 
>>> 
>>> Thanks for raising the thread, I remember there was some confusion early 
>>> wrt features branches too.
>>> 
>>> To rehash, for everything currently resolved in trunk 5.0 is the correct 
>>> fixVersion.  (And there should be no unresolved issues today with 5.0 
>>> fixVersion, they should be 5.x)
>>> 
>>> 
>>> When alpha1 is cut, then the 5.0-alpha1 fixVersion is created and 
>>> everything with 5.0 also gets  5.0-alpha1. At the same time 5.0-alpha2, 
>>> 5.0-beta, 5.0-rc, 5.0.0 fixVersions are created. Here both 5.0-beta and 
>>> 5.0-rc are blocking placeholder fixVersions: no resolved issues are left 
>>> with this fixVersion the same as the .x placeholder fixVersions. The 5.0.0 
>>> is also used as a blocking version, though it is also an eventual 
>>> fixVersion for resolved tickets. Also note, all tickets up to and including 
>>> 5.0.0 will also have the 5.0 fixVersion.
>>> 
>>> 
>>> 
>>> A particular reason for doing things the way they are is to make it easy 
>>> for the release manager to bulk correct fixVersions, at release time or 
>>> even later, i.e. without having to read the ticket or go talk to authors or 
>>> painstakingly crawl CHANGES.txt.
>>> 
>>> 
>>> 
>>> For feature branches my suggestion is that we create a fixVersion for each 
>>> of them, e.g. 5.0-cep-15
>>> 
>>> Yup, that's your suggestion Jeremiah (I wrote this up on the plane before I 
>>> got to read your post properly).
>>> 
>>> 
>>> 
>>> (As you say) This then makes it easy to see where the code is (or what the 
>>> patch is currently being based on). And when the feature branch is merged 
>>> then it is easy to bulk replace it with trunk's fixVersion, e.g.  
>>> 5.0-cep-15 with 5.0
>>> 
>>> 
>>> 
>>> The NA fixVersion was introduced for the other repositories, e.g. website 
>>> updates.
>>> 

Re: [DISCUSS] Feature branch version hygiene

[Caleb Rackliffe]

...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 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  wrote:
>
>>
>>
>> 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 is also using the feature branch method the
>>> "reviewed and merged to feature branch" tickets seem to be given a version
>>> of NA.
>>>
>>>
>>> Not sure that's the best “waiting for cep to merge” version either?  But
>>> it seems better than putting 5.0 on them to me.
>>>
>>>
>>> Why I’m not keen on 5.0 is because if we cut the release today those
>>> tickets would not be there.
>>>
>>>
>>> What do other people think?  Is there a better version designation we
>>> can use?
>>>
>>>
>>> On a different project I have in the past made a “version number” in
>>> JIRA for each long running feature branch. Tickets merged to the feature
>>> branch got the epic ticket number as their version, and then it got updated
>>> to the “real” version when the feature branch was merged to trunk.
>>>
>>
>>
>> Thanks for raising the thread, I remember there was some confusion early
>> wrt features branches too.
>>
>> To rehash, for everything currently resolved in trunk 5.0 is the correct
>> fixVersion.  (And there should be no unresolved issues today with 5.0
>> fixVersion, they should be 5.x)
>>
>>
>> When alpha1 is cut, then the 5.0-alpha1 fixVersion is created and
>> everything with 5.0 also gets  5.0-alpha1. At the same time 5.0-alpha2,
>> 5.0-beta, 5.0-rc, 5.0.0 fixVersions are created. Here both 5.0-beta and
>> 5.0-rc are blocking placeholder fixVersions: no resolved issues are left
>> with this fixVersion the same as the .x placeholder fixVersions. The 5.0.0
>> is also used as a blocking version, though it is also an eventual
>> fixVersion for resolved tickets. Also note, all tickets up to and
>> including 5.0.0 will also have the 5.0 fixVersion.
>>
>>
>> A particular reason for doing things the way they are is to make it easy
>> for the release manager to bulk correct fixVersions, at release time or
>> even later, i.e. without having to read the ticket or go talk to authors
>> or painstakingly crawl CHANGES.txt.
>>
>>
>> For feature branches my suggestion is that we create a fixVersion for
>> each of them, e.g. 5.0-cep-15
>>
>> Yup, that's your suggestion Jeremiah (I wrote this up on the plane before
>> I got to read your post properly).
>>
>>
>> (As you say) This then makes it easy to see where the code is (or what
>> the patch is currently being based on). And when the feature branch is
>> merged then it is easy to bulk replace it with trunk's fixVersion, e.g.  
>> 5.0-cep-15
>> with 5.0
>>
>>
>> The NA fixVersion was introduced for the other repositories, e.g. website
>> updates.
>>
>

Re: [DISCUSS] Feature branch version hygiene

[Caleb Rackliffe]

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  wrote:

>
>
> 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 is also using the feature branch method the
>> "reviewed and merged to feature branch" tickets seem to be given a version
>> of NA.
>>
>>
>> Not sure that's the best “waiting for cep to merge” version either?  But
>> it seems better than putting 5.0 on them to me.
>>
>>
>> Why I’m not keen on 5.0 is because if we cut the release today those
>> tickets would not be there.
>>
>>
>> What do other people think?  Is there a better version designation we can
>> use?
>>
>>
>> On a different project I have in the past made a “version number” in JIRA
>> for each long running feature branch. Tickets merged to the feature branch
>> got the epic ticket number as their version, and then it got updated to the
>> “real” version when the feature branch was merged to trunk.
>>
>
>
> Thanks for raising the thread, I remember there was some confusion early
> wrt features branches too.
>
> To rehash, for everything currently resolved in trunk 5.0 is the correct
> fixVersion.  (And there should be no unresolved issues today with 5.0
> fixVersion, they should be 5.x)
>
>
> When alpha1 is cut, then the 5.0-alpha1 fixVersion is created and
> everything with 5.0 also gets  5.0-alpha1. At the same time 5.0-alpha2,
> 5.0-beta, 5.0-rc, 5.0.0 fixVersions are created. Here both 5.0-beta and
> 5.0-rc are blocking placeholder fixVersions: no resolved issues are left
> with this fixVersion the same as the .x placeholder fixVersions. The 5.0.0
> is also used as a blocking version, though it is also an eventual
> fixVersion for resolved tickets. Also note, all tickets up to and
> including 5.0.0 will also have the 5.0 fixVersion.
>
>
> A particular reason for doing things the way they are is to make it easy
> for the release manager to bulk correct fixVersions, at release time or
> even later, i.e. without having to read the ticket or go talk to authors
> or painstakingly crawl CHANGES.txt.
>
>
> For feature branches my suggestion is that we create a fixVersion for each
> of them, e.g. 5.0-cep-15
>
> Yup, that's your suggestion Jeremiah (I wrote this up on the plane before
> I got to read your post properly).
>
>
> (As you say) This then makes it easy to see where the code is (or what
> the patch is currently being based on). And when the feature branch is
> merged then it is easy to bulk replace it with trunk's fixVersion, e.g.  
> 5.0-cep-15
> with 5.0
>
>
> The NA fixVersion was introduced for the other repositories, e.g. website
> updates.
>

Re: [DISCUSS] Feature branch version hygiene

[Mick Semb Wever]

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 is also using the feature branch method the
> "reviewed and merged to feature branch" tickets seem to be given a version
> of NA.
>
>
> Not sure that's the best “waiting for cep to merge” version either?  But
> it seems better than putting 5.0 on them to me.
>
>
> Why I’m not keen on 5.0 is because if we cut the release today those
> tickets would not be there.
>
>
> What do other people think?  Is there a better version designation we can
> use?
>
>
> On a different project I have in the past made a “version number” in JIRA
> for each long running feature branch. Tickets merged to the feature branch
> got the epic ticket number as their version, and then it got updated to the
> “real” version when the feature branch was merged to trunk.
>


Thanks for raising the thread, I remember there was some confusion early
wrt features branches too.

To rehash, for everything currently resolved in trunk 5.0 is the correct
fixVersion.  (And there should be no unresolved issues today with 5.0
fixVersion, they should be 5.x)


When alpha1 is cut, then the 5.0-alpha1 fixVersion is created and
everything with 5.0 also gets  5.0-alpha1. At the same time 5.0-alpha2,
5.0-beta, 5.0-rc, 5.0.0 fixVersions are created. Here both 5.0-beta and
5.0-rc are blocking placeholder fixVersions: no resolved issues are left
with this fixVersion the same as the .x placeholder fixVersions. The 5.0.0
is also used as a blocking version, though it is also an eventual
fixVersion for resolved tickets. Also note, all tickets up to and including
5.0.0 will also have the 5.0 fixVersion.


A particular reason for doing things the way they are is to make it easy
for the release manager to bulk correct fixVersions, at release time or
even later, i.e. without having to read the ticket or go talk to authors or
painstakingly crawl CHANGES.txt.


For feature branches my suggestion is that we create a fixVersion for each
of them, e.g. 5.0-cep-15

Yup, that's your suggestion Jeremiah (I wrote this up on the plane before I
got to read your post properly).


(As you say) This then makes it easy to see where the code is (or what the
patch is currently being based on). And when the feature branch is merged
then it is easy to bulk replace it with trunk's fixVersion, e.g.  5.0-cep-15
with 5.0


The NA fixVersion was introduced for the other repositories, e.g. website
updates.

Re: [DISCUSS] Feature branch version hygiene

[Ekaterina Dimitrova]

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
until the feature branch is merged.

“ Why I’m not keen on 5.0 is because if we cut the release today those
tickets would not be there.”

I guess it can make it easier also from Release Management process as if I
remember correctly there is a script that changes potentially all tickets
resolved with major version (in this case 5.0) to 5.0-alpha or whatever we
stop on to be the release version.

Though NA can be confusing I guess. Shall we use something like
5.0-candidate, 6.0-candidate? This can be based on the confidence people
have around a feature branch, where it can potentially land. I am curious
how other projects do it too.

I think it is a good call to decide on something and document it. I can
imagine it will be also easier during release management. Thank you
Jeremiah for raising the topic

Best regards,
Ekaterina


On Tue, 16 May 2023 at 16:04, Benedict  wrote:

> 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 in.
> There's always ambiguity over the next release, as it's sort of both. But
> since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
> landed upon last time.
>
> Work that has actually landed should probably be labelled as 5.0-alpha1
>
> On 16 May 2023, at 21: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 is also using the feature branch method the
> "reviewed and merged to feature branch" tickets seem to be given a version
> of NA.
>
>
> Not sure that's the best “waiting for cep to merge” version either?  But
> it seems better than putting 5.0 on them to me.
>
>
> Why I’m not keen on 5.0 is because if we cut the release today those
> tickets would not be there.
>
>
> What do other people think?  Is there a better version designation we can
> use?
>
>
> On a different project I have in the past made a “version number” in JIRA
> for each long running feature branch. Tickets merged to the feature branch
> got the epic ticket number as their version, and then it got updated to the
> “real” version when the feature branch was merged to trunk.
>
>
> -Jeremiah
>
>

Re: [DISCUSS] Feature branch version hygiene

[Caleb Rackliffe]

...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 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:04 PM Benedict  wrote:
>
>> 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
>> in. There's always ambiguity over the next release, as it's sort of both.
>> But since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
>> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
>> landed upon last time.
>>
>> Work that has actually landed should probably be labelled as 5.0-alpha1
>>
>> On 16 May 2023, at 21: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 is also using the feature branch method the
>> "reviewed and merged to feature branch" tickets seem to be given a version
>> of NA.
>>
>>
>> Not sure that's the best “waiting for cep to merge” version either?  But
>> it seems better than putting 5.0 on them to me.
>>
>>
>> Why I’m not keen on 5.0 is because if we cut the release today those
>> tickets would not be there.
>>
>>
>> What do other people think?  Is there a better version designation we can
>> use?
>>
>>
>> On a different project I have in the past made a “version number” in JIRA
>> for each long running feature branch. Tickets merged to the feature branch
>> got the epic ticket number as their version, and then it got updated to the
>> “real” version when the feature branch was merged to trunk.
>>
>>
>> -Jeremiah
>>
>>

Re: [DISCUSS] Feature branch version hygiene

[Caleb Rackliffe]

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:04 PM Benedict  wrote:

> 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 in.
> There's always ambiguity over the next release, as it's sort of both. But
> since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
> landed upon last time.
>
> Work that has actually landed should probably be labelled as 5.0-alpha1
>
> On 16 May 2023, at 21: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 is also using the feature branch method the
> "reviewed and merged to feature branch" tickets seem to be given a version
> of NA.
>
>
> Not sure that's the best “waiting for cep to merge” version either?  But
> it seems better than putting 5.0 on them to me.
>
>
> Why I’m not keen on 5.0 is because if we cut the release today those
> tickets would not be there.
>
>
> What do other people think?  Is there a better version designation we can
> use?
>
>
> On a different project I have in the past made a “version number” in JIRA
> for each long running feature branch. Tickets merged to the feature branch
> got the epic ticket number as their version, and then it got updated to the
> “real” version when the feature branch was merged to trunk.
>
>
> -Jeremiah
>
>

Re: [DISCUSS] Feature branch version hygiene

[Benedict]

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 in. 
There's always ambiguity over the next release, as it's sort of both. But since 
there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, perhaps 5.0 is 
the correct label (and makes sense to me). I forget what we landed upon last 
time.
Work that has actually landed should probably be labelled as 5.0-alpha1

> On 16 May 2023, at 21: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 is also using the feature branch method the "reviewed 
> and merged to feature branch" tickets seem to be given a version of NA.
> 
> Not sure that's the best “waiting for cep to merge” version either?  But it 
> seems better than putting 5.0 on them to me.
> 
> Why I’m not keen on 5.0 is because if we cut the release today those tickets 
> would not be there.
> 
> What do other people think?  Is there a better version designation we can use?
> 
> On a different project I have in the past made a “version number” in JIRA for 
> each long running feature branch. Tickets merged to the feature branch got 
> the epic ticket number as their version, and then it got updated to the 
> “real” version when the feature branch was merged to trunk.
> 
> -Jeremiah