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