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