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 <mailto: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 >>>>>> <mailto:m...@apache.org>> wrote: >>>>>> >>>>>> >>>>>> On Tue, 16 May 2023 at 13:02, J. D. Jordan <jeremiah.jor...@gmail.com >>>>>> <mailto: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.
