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