Redmine "Fixed in" and "Target Version"


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.

Let me know what you think.


Can we set this field automatically, e.g. using prprocessor?


That would be great. At least for develop if it’s too complicated for other branches.

I would love that, if we agree on this workflow it should be fairly simple i think.

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

No, it’s single-valued, sadly. @tbrisker how should we handle that?

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.

Not right now because it looks at different fields, but there is code to verify commits from an issue are in a branch.

I see where you’re coming from but naming is hard. Name that one Target version? :slight_smile: