Indicate with which precise release(s) an issue was fixed?

We are migrating from JIRA to GitLab and we are wondering what is the equivalent of the JIRA field Fix Version/s in GitLab.

In JIRA this field is used to indicate with which precise version (or versions) an issue is fixed.

As a software vendor it is highly possible that you fix a bug in multiple versions (like the bug is fixed in an old maintenance branch: 3.7.4 and in your latest major version: 4.1.3)

The purpose of this is:

  • To generate the release notes for each of your released version
  • Later if you discover that a change has introduced a regression, you would like to compute the list or the ranges of the affected versions.

I have read that “Milestones” can be used to track releases (Milestones | GitLab), but in this case I do not see how to implement the use-case of multiple fixed versions (each issue has only one associated milestone)

But I am also not sure what the other GitLab option can be used for this. Using labels (even by using Scoped-label) seems also wrong (the list will always grow over time).

I appreciate some feedback in any direction…

I would use Labels as follows:

You will be able to leverage this feature to find easily all issues fixed of a specific release.

Currently our project (>10 years old) contains 720 versions in Jira.
I am not sure it make sense to model this with labels.
We will probably not migrate our JIRA history, so this number of releases isn’t a problem.
But to give you more realistic numbers last year (in 2021) we created ~90 releases.

Are you sure that labels can really be used from an UX perspective?

Especially taking into account that we will need to use scoped-labels as well to map our current workflow (OPEN, TRIAGE, IN PROGRESS, RESOLVED, TESTED BY QA, …) and issue type (BUG, NEW-FEATURE, REMOVAL, …)

Labels seems to be the universal answer for advanced issue management at GitLab.


Also in JIRA a version has the status:

  • Released
  • Unreleased

And the UI is using this information to provide a really good user experience:

When you create a new issue, it suggests you only:

  • Already released versions for the Affects Version/s field (we are not really using this feature, but it makes sense)
  • Only unreleased versions by default for the Fix Version/s field (you can bypass the initial selection suggested in the drop-down, because sometimes you fix the metadata of older issues and you indicate that they were fixed with a version that is currently already released)

I had a look at how GitLab itself is working, and they really seems to use labels to indicate with which version an issue was fixed: