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