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 <jmcken...@apache.org> 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 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 <jmcken...@apache.org> 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.
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?
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.
|
