User defined merge request versions

Problem to Solve

Currently the term merge request versions applies to version selectors based on each available SHA within a merge request. There is no logical grouping to those versions and comparisons between them might actually need to be several different points in time.

Versions in merge requests also have special powers to make discussions outdated and remove them from the changes tab, but leave them in the overview tab. Even simple changes like punctuation might create a new version without addressing the core feedback that was provided during the review.

Proposal

Merge request authors should be able to create versions of the entire merge request. Versions would be a collection of commits, pipelines, comments, suggestions, approvals and other important data that is tagged by the author at specific points of time.

Additional Details

As an author of a merge request, I'd propose my initial set of changes. This is version 1 of the merge request. Once I've submitted my proposal comments would be left by various reviewers, approvals would be given and a pipeline would run. I would take the feedback from all of these things and make more commits to address the feedback, pipeline errors and other items. When I was satisfied I had addressed these items, I would tag a new version (version 2) of the merge request.

Version 2 of the merge request would effectively be a clean slate with metadata to support the items resolved from the previous review.

This process would continue until the merge request was merged.

Why this?

This effectively creates a user controlled version process which eliminates the need for multiple tabs and other bits competing for where they are in the workflow and uses versions to control that.