I would vote for option 1. We have done similar in the past and if something is a blocker it means it will be in that version before it is released. So there should not be any confusion of things getting bumped forward to another patch number because they were not committed in time, which is where confusion usually arises from.
> On May 9, 2022, at 4:07 PM, Mick Semb Wever <m...@apache.org> 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). > > >
