And back to the point - 4.1.0 which? Alpha, beta or rc? As we have that on the table too.
On Mon, 9 May 2022 at 18:59, David Capwell <dcapw...@apple.com> wrote: > I am in favor of option 1. If you are 4.1.0 and not resolved, then we > either need to kick you out of the 4.1.0 release (as you are not a blocker) > or you are a blocker for that release and must be fixed in 4.1.0 > > > On May 9, 2022, at 2:49 PM, bened...@apache.org wrote: > > I think this is close to what we settled on last we hashed this out. > > > *From: *Josh McKenzie <jmcken...@apache.org> > *Date: *Monday, 9 May 2022 at 22:47 > *To: *dev@cassandra.apache.org <dev@cassandra.apache.org> > *Subject: *Re: How we flag tickets as blockers during freeze > As you mentioned on slack, we can introduce FixVersions for the unreleased > interim versions specified in the lifecycle wiki ( > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), > so add the following specific *unresolved placeholder FixVersions*: > > 4.1-alpha > 4.1-beta > 4.1-rc > > Thus anything unresolved flagged 4.1-alpha would be a blocker for that, > same for beta and rc. When the tickets are closed, we switch them to > FixVersion 4.1; I don't see there being much value in knowing in the future > if a ticket is fixed during the alpha, beta, or rc phases by using the > above as resolved FixVersions. > > This approach potentially breaks down if we have any final blockers on 4.1 > ga, but could just cycle through 4.1-rc until it's all clear. > > On Mon, May 9, 2022, at 5:07 PM, Mick Semb Wever wrote: > > Any other opinions or ideas out there? Would like to tidy our tickets up > as build lead and scope out remaining work for 4.1. > > > > My request is that we don't overload fixVersions. That is, a fixVersion is > either for resolved tickets, or a placeholder for unresolved, but never > both. > This makes it easier with jira hygiene post release, ensuring issues do > get properly assigned their correct fixVersion. (This work can be many > tickets and already quite cumbersome, but it is valued by users.) > > It would also be nice to try keep what is a placeholder fixVersion as > intuitively as possible. The easiest way I see us doing this is to avoid > using patch numbers. This rules out Option 1. > > While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the > above notion of "if it doesn't have a patch version then it's a > placeholder". The precedence here is that all resolved tickets before the > first .0 of a major gets this short-hand version (and often in addition to > the alpha1, beta1, rc1 fixVersions). > > >
