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).
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)
@jmini, I suggest you file an issue, considering that it seems like both you and GitLab would significantly benefit from a proper implementation of this feature.