Redmine release fields

Hello,

Since there was much confusion with regards to the new release fields in redmine, I thought it would be best to clarify how we currently use them in the Foreman core projects (foreman, installer, proxy, selinux):

  • Target Version - If an issue has not been fixed yet, and you believe it should be part of a certain release, please set this to the earliest version you think in should be in (e.g., if you want the fix to be in 1.18.2, that implies it should also be in the next 1.19 and 1.20 releases). Keep in mind this does not guarantee the issue will block the release, as that decision will be made by the specific release team.
  • Found in Releases - If you know which commit introduced a certain bug, this is a good indication to say which releases are affected by it (e.g., a bug introduced in 1.19 will not require the fix being backported to 1.18). If not, any release the issue is found in can be set. This is especially important for security issues as they require indicating precisely the affected versions.
  • Fixed in Releases - Which versions the actual fix landed in. When merging a PR to develop, please add the next release here (1.20.0 at the time of writing). When cherry-picking a release to a stable branch (whether directly by the release team or via PR), add the next release in that branch (e.g. 1.18.2 for fixes merged into 1.18-stable at the time of writing).

Keep in mind that other projects may use these fields differently, if in doubt reach out to the maintainers of the specific project.
If you are a maintainer of a project that uses the same or a different workflow, please comment below and share what should be done in your project.

2 Likes

One more clarification, that is relevant mostly for the period between branching and release of a new version: An issue should only have one .0 fixed in release, set to the first major release including it. This is to prevent the same bug from appearing in the release notes for two main releases. It is fine if it is back-ported to have it in the release notes for e.g. .1 release to indicate it was back ported, but any fix cherry picked from the develop branch to the stable branch before release should have the fixed in changed from the next release to the current one.

To make it simpler with an example - if 1.90 is branched on August 1st, 2025 and released on August 20th 2025 then:

  • issue merged into develop before August 1st = fixed in release set to 1.90.0
  • issue merged into develop on August 10 = fixed in release set to 1.91.0
  • if above issue is merged into 1.90-stable on August 12 = fixed in release set to 1.90.0 instead of 1.91.0
  • if above issue is merged into 1.90-stable on August 25 = fixed in release set to 1.91.0 and 1.90.1