As part of the upgrade we added a multi-select field for “Fixed in releases” to Redmine. I suggest we use these fields with the following workflow:
Target version should be used to indicate what is the first version we want this to land in. It can be set before the issue is fixed to indicate this should be a blocker for a certain release.
Fixed in releases indicates which release branches the fix has actually been merged into. This means you need to update this once you merge a commit to develop or cherry-pick to a release branch, to the next release in the relevant branch. For example, if now I merge something into develop and cherry-pick it to 1.18-stable and 1.19-stable, I will set the fixed in field to “1.18.1, 1.19.0, 1.20.0”. This field will be used to generate the release notes for each version.
@Gwmngilfen Is it possible to configure redmine to have multiple target versions? For example, recently I wanted #24298 to go in 1.19 and 1.18.1. I marked ‘target version’ 1.18.1, so for it to land in 1.19 I actively have to chase the release manager as the issue will not show automatically in their TODO list.
I’d argue we drop Target version altogether. If we determine something should go in a release, we should add it to Fixed in release. Then at release time you can check if all the cherry picks made it in or not. tool_belt has some code to do this already, we just need to look at different fields. After that it can even suggest the commands to cherry pick.
The PR processor can still set the Fixed in value if a cherry pick is merged without it being targetted.
I’m fine with removing the target version completely once we’ve made sure all issues with a target version also have it in the fixed in field. My only concern is that we might miss issues that people target for stable versions by setting the fixed in field but the cherrypick was never done, and because the issue was closed on develop we don’t notice it, or don’t notice that is should be a blocker for a release. I guess toolbelt can/should handle that though?
Your proposing we have a single field to represent what release an issue is targeted to or in? I agree with that sentiment. However, I find the nomenclature “Fixed in” a bit odd when discussing a release. The naming has an implication something is fixed already where as a user has to double check the status. I see that raising confusion questions. All that is to say, I am all for a single field to represent what release or version something is in but let’s change the naming.
