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 > <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).
