Allow milestone(s) to be associated with a release
Problem to solve
Releases in GitLab are not yet well associated with other data that exists in the single application. A clear starting point that's missing today is associating a milestone with a release. The way many teams use GitLab, ourselves included, is to have a milestone for the release that everything tracks to. Some teams also have 2 or 3 sprints that may make up a release, so we should allow for multi-association.
Intended users
Release Managers, users who want to see what was included in a release.
Further details
In the future, having the milestone will make it easier to automatically generate release notes for a release as well as other potential improvements.
Proposal
- API: Add a new milestone list that associates a release with zero or more milestones (we would support more than one to support milestones as sprints, for example)
- Even though the MVC for this new feature will only allow one milestone for one release, it was decided to go ahead and implement the long-term architecture.
- UI: For each associated milestone, link from the release home to the milestone home (https://gitlab.com/groups/gitlab-org/-/milestones/20).
- UI: Also link directly to MR and issues search links for each milestone (same as the issue/MR links at the bottom of the above page).
- UI: Link from tags page/other places we show tag to release, if a release is associated.
UX proposal
- There isn't an edit interface added yet (see #26016 (closed)), but the new element needs to be handled and displayed correctly in the UI.
- We display the milestones ordered alphanumerically
- Even though the MVC for this new feature will only allow one milestone for one release, it was decided to go ahead and design the long-term solution.
User story
As a user, I want to know when a milestone is associated to a release, so that I see issues and merge requests included in a release.
Prototypes
| Releases page - no milestones | Updates | |
|---|---|---|
 |
N/A. If no Milestone is set for a release, the information should not be rendered on screen. |
| Releases page - multiple milestones | Updates | |
|---|---|---|
 |
Add a Milestone 00.00 • 00.00 data point to each Release entry. The release number link should take users to the individual Milestone home page. |
Add a reference to View [Issues] or [Merge Requests] in this Release to each Release entry. Issues should link to all issues labeled under the milestone. Merge Requests should link to all merge request labeled under the milestone. |
| Tags page | Updates |
|---|---|
 |
Add a Release 00.00 link to each Tag entry. The link should take users to the specified release entry in the Releases page page. An anchor should be specified based on the release tag. The page should scroll to the given anchor. If no Release is set for a tag, the information should not be rendered on screen. |
| Milestones page | Updates |
|---|---|
 |
Add a Release [v00.00] link to each Milestone entry. The link should take users to the specified release entry in the Releases page page. An anchor should be specified based on the release tag. The page should scroll to the given anchor. If no Milestone is set for a tag, the information should not be rendered on screen. |
| Milestones detail page | Updates |
|---|---|
 |
On the side panel (right), add a data entry for the Release linked to the milestone. Release [v00.00]. The text should link to the releases page. Clicking the link should take the user to the specified release entry in the Releases page page. An anchor should be specified based on the release tag. The page should scroll to the given anchor. If no Release is set for a Milestone, the label should read None. |
Screenshots of actual implementation
Releases page
Tags page
Milestone list page
Milestone detail page
FE considerations
Milestone / Release. Change the words displayed, depending on the number qualifying the word. For example: Milestone 12.1 vs Milestones 12.2, 12.3. Different languages can have different rules.
- The releases/milestones items displayed inline in the UI should wrap in a new line if there's not enough horizontal space to display it.
Permissions and Security
No additional permissions or security are required. The current users who can update releases should continue to be able to do so, and no changes to visibility are required.
Documentation
This is a new kind of association, so we need to update both tags documentation and releases documentation to describe this new kind of relationship.
Testing
What does success look like, and how can we measure that?
We should measure releases associated with milestones as a usage measure for this feature.
Although this feature is valuable on its own to link to MRs/issues in a given release, the real beauty will come when we start autogenerating release notes based on this content. It makes more sense to measure success of releases once that is available.
Links / references
Slack channel: #f_milestone_release
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.