Add first-class semantic versioning to Releases
Problem to solve
Releases are tightly tied to Git tags (the tag name is the Release's de facto primary identifier), which is problematic for some use cases:
- Guest users of private projects are allowed to view Releases, but not allowed to access any Git info, including the tag name. See #213016 (closed).
- We have the ability to label a Release as an "upcoming Release", but these Releases still require an association to a existing Git tag, making this feature less useful.
Proposal 1
- Add a "version" field to Releases that conforms to semantic versioning.
- Use this version as the Release's primary identifier instead of the Git tag name.
Proposal 2
- Use GitVersion to automatically create a Git Tag
Other benefits
Sorting/filtering of Releases
A semantic version field would be useful when sorting and filtering Releases (see #26413 (closed)). This would allow this page to organize/group/filter Releases more intelligently, for example:
- Only show major versions (
X.0.0), or filter our patch versions - Only show versions for a specific major version (
12.X.X) - Sort releases by version (
12.0.0-alpha,12.0.0-beta,12.0.0,12.0.1,12.1.0)
Cross-over/collaboration with GitLab's Package features
GitLab's Package registry already tracks packages using a first-class "version" concept, so making Releases aware of versioning would allow some cool integrations between these two features. For example:
- Automatically creating Releases when a package is published
- Merging of the Releases and the Packages page
Intended users
Mostly Rachel (Release Manager)
Further details
Item #2 in the Proposal section above would require a significant amount of development work:
- Use this version as the Release's primary identifier instead of the Git tag name.
In addition, we would need to come up with a transition plan for projects that have existing Releases. We already recommend using semantic versioning in our documentation, so hopefully most projects could be automatically converted by parsing the existing Releases' tag names.
Permissions and Security
This would alleviate some of issues we have regarding Guest users of private projects: #213016 (closed)
Documentation
This feature would require documentation updates, primarily on this page.
Is this a cross-stage feature?
As mentioned above, this feature could open up some opportunities to collaborate with Package.