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