Merge requests based changelogs
Release notes
Merge requests based changelogs (as an alternative to commit based changelogs).
Problem to solve
Currently, Gitlab has some built-in ability to generate changelogs through API/CLI/CI. It uses git commit trailers as a source for changelogs. This approach does not work well with all workflows: it requires squashing commits, messages cannot easily be editted after merge, it mixes commit messages (mostly for devs) and changelog (mostly for management/users), etc.
An alternative is to base the changelog on merge requests, which often come with additional information about a fix/feature (discussion, iterations, implementation details, screenshots, ci, etc.).
This is how Github's Generate release note button on the release creation page works.
Intended users
Developers: when documenting a feature, they already open a MR with a clear title and a description. This way they don't need to think about their git trailer when they commit or squash&merge a merge request. Even after a merge, they can come back and improve upon the MR title or description.
Release Manager: can update merge requests titles after merge to improve both their changelog and their mr history at once.
User experience goal
See above
Proposal
Add an argument merge-requests mutually exclusive with existing trailer to the API/CLI.
When provided, switches to "merge request" mode instead of "git trailer mode".
Merge requests are retrieved based on the commit in the given range (probably using the same logic as https://docs.gitlab.com/ee/api/commits.html#list-merge-requests-associated-with-a-commit)
Otherwise, all existing workflows should work in the same way (possibility to commit the changelog, or just generate it).
In future iterations, we could include some more fine-tuning for configuring the changelog (e.g. include/exclude authors/labels, see github's doc).
Further details
n/a
Permissions and Security
n/a
Documentation
n/a
Availability & Testing
n/a
Available Tier
Free of course (but this being a "nice to have" thing, could understand it only ends up in paid tiers)
Feature Usage Metrics
n/a
What does success look like, and how can we measure that?
Number of time the merge_request mode is used to generate changelog (>20%).
What is the type of buyer?
n/a
Is this a cross-stage feature?
n/a
What is the competitive advantage or differentiation for this feature?
Be on par with github