I don’t think we should over complicate this with special CEP release targets. If we do, they shouldn’t be versioned.
My personal view is that 5.0 should not be used for any resolved tickets - they should go to 5.0-alpha1, since this is the correct release for them. 5.0 can then be the target version, which makes more sense given it isn’t a concrete release.
But, in lieu of that, every ticket targeting 5.0 could use fixVersion 5.0.x, since it is pretty clear what this means. Some tickets that don’t hit 5.0.0 can then be postponed to a later version, but it’s not like this is burdensome. Anything marked feature/improvement and 5.0.x gets bumped to 5.1.x.
On 18 May 2023, at 13:58, Josh McKenzie <jmcken...@apache.org> wrote:
CEP-N seems like a good compromise. NextMajorRelease bumps into our interchangeable use of "Major" and "Minor" from a semver perspective and could get confusing. Suppose we could do NextFeatureRelease, but at that point why not just have it linked to the CEP and have the epic set.
On Thu, May 18, 2023, at 12:26 AM, Caleb Rackliffe wrote:
...otherwise I'm fine w/ just the CEP name, like "CEP-7" for SAI, etc.
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?
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.
|
