I do not think we discussed it from feature branch perspective. (Happy to stand corrected but I did not find anything in @dev archive myself) But we do mark with 5.0 anything that lands in trunk. I think it might be a good idea anything that lands in a feature branch to have different fix version until the feature branch is merged.
“ Why I’m not keen on 5.0 is because if we cut the release today those tickets would not be there.” I guess it can make it easier also from Release Management process as if I remember correctly there is a script that changes potentially all tickets resolved with major version (in this case 5.0) to 5.0-alpha or whatever we stop on to be the release version. Though NA can be confusing I guess. Shall we use something like 5.0-candidate, 6.0-candidate? This can be based on the confidence people have around a feature branch, where it can potentially land. I am curious how other projects do it too. I think it is a good call to decide on something and document it. I can imagine it will be also easier during release management. Thank you Jeremiah for raising the topic Best regards, Ekaterina On Tue, 16 May 2023 at 16:04, Benedict <bened...@apache.org> wrote: > 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 > >
