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