> 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. Ahhhhhhhhhhh.
> 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 <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. >>>>> >>>>> On Wed, May 17, 2023 at 11:24 PM Caleb Rackliffe >>>>> <calebrackli...@gmail.com> 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 <m...@apache.org> wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, 16 May 2023 at 13:02, J. D. Jordan <jeremiah.jor...@gmail.com> >>>>>>> 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. >>>>>>> >>>> >>
