...but that and "What do we do with things that might be in 5.0 and might not?" are different questions.
A version that denotes "next major release" until merged (at which point it could be given a real version) could be helpful... On Tue, May 16, 2023 at 3:28 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > I like the NA approach for sub-tasks that roll up to a parent/epic ticket. > When that lands, it gets a real version, and any sub-task is assumed to > also have that version. > > Not that it has to be called "NA", but there should be something to denote > "inherits from parent". > > On Tue, May 16, 2023 at 3:04 PM 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 >> >>
