I've updated all the 4.1.x tickets to be either 4.1-beta or 4.1-rc (we didn't have any API changers that'd qualify for alpha blockers).
Kanban board swimlanes and quick filters are updated; a link to the board showing our open tickets blocking 4.1 GA can be found here: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455 Thanks! ~Josh On Wed, May 11, 2022, at 12:30 AM, Berenguer Blasi wrote: > +1 also from me. Merging versions or bulk updating should solve the post > release version consolidation. We just need to enable that if that'd be > the case. > > On 10/5/22 16:20, J. D. Jordan wrote: > > +1 from me. > > > >> On May 10, 2022, at 9:17 AM, Josh McKenzie <jmcken...@apache.org> wrote: > >> > >> > >>> at some later point it needs to be "easy" for > >>> someone else to correct it. > >> I don't want to optimize for cleaning up later; I want to optimize for our > >> ability to know our workload blocking our next release and encouraging > >> contributors to focus their efforts if they're so inclined. > >> > >> That said, I'm in favor now of adding the unreleased versions for -alpha, > >> -beta, and -rc, and flipping to the major/minor on resolution. We should > >> also codify this in our release lifecycle wiki article so we don't have to > >> revisit the topic. > >> > >> I think this solution is compatible with what everyone on the thread has > >> said thus far, so if nobody has any major concerns, later today I will: > >> > >> 1. Add a 4.1-alpha, 4.1-beta, and 4.1-rc FixVersion (unreleased) > >> 2. Update fixversion on tickets that are blocking each release > >> respectively based on our lifecycle process > >> 3. Update our kanban board to have swimlanes for each phase of the release > >> 4. Update the lifecycle cwiki w/this process for future releases > >> > >> ~Josh > >> > >>> On Tue, May 10, 2022, at 2:23 AM, Mick Semb Wever wrote: > >>>> Why do you need to change anything post release? The whole point is to > >>>> set the version to the release the ticket blocks. So you don’t need to > >>>> change anything. > >>>> > >>> > >>> There's always many issues left with the wrong fixVersion. And we > >>> can't police that. So at some later point it needs to be "easy" for > >>> someone else to correct it. > >>> >
