Copying my rely on the ticket… We have this discussion roughly once per major. If you look back through dev@ you'll find the last one a few years back. I don't recall NA ever being the approved approach, though. ".x" lines are target versions, whereas concrete versions are the ones a fix landed in. There's always ambiguity over the next release, as it's sort of both. But since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, perhaps 5.0 is the correct label (and makes sense to me). I forget what we landed upon last time. Work that has actually landed should probably be labelled as 5.0-alpha1
> On 16 May 2023, at 21: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. > > -Jeremiah
