Define the Templating System - Release Message

[Eomm]

We could use labels (between two releases) and/or the commit messages

What could be the best choice? Could we do both? Should we use a pattern like https://keepachangelog.com/ ?

For sure we need to track a "modus-operandi" cause some PR we need to track the author.

[mcollina]

I think we should require none by default. These should be configurable as well as the template for the release notes.

Note that we should be able to configure the tool with labels, but we don’t want to create labels on 30-something repos on this org (and many more on other orgs). Essentially this work well as a “just works” tool.

[delvedor]

Multi-branch support would be great as well.

[Eomm]

I was thinking that a command setup could be useful to add to a GitHub repo some label (configured) in order to facilitate the process

Relates to #1

[mcollina]

That should not be needed. We should be able to use this without any specific configs - while configs might enhance the flow.

Otherwise this will not be different from semantic-release, which dictates and governs the release flow.

[Eomm]

The use case I had in mind was: I have many repo (50 plugins) and I would like to add semver-* labels to them in order to have all the repos as the main one -in order to have the same logic apply to all of them.

But yes, maybe this is only another tool that runs once

[mcollina]

That’s ok, it’s a great idea. My only requirement is that the step should not be mandatory, but rather support for advanced features.

[Eomm]

Backing back to the template system for the release message.

The pattern could be: 1 title => 1 semver version corresponding => array of labels

if the PR's labels don't find any match, we should:

1. apply a default
2. force the manual edit of the message and the input of the --semver parameter
3. interrupt the publish command

ex: 🆕 Cool Feature => minor => [minor] 🆕 Less Cool Feature => minor => [less-minor] 🏹🐛 Bug fix ✌ => patch => [bug, bugfix, documentation]

[mcollina]

I'm +1 with the proposed approach.

[Eomm]

I think we should call this GH api: https://docs.github.com/en/rest/releases/releases#generate-release-notes-content-for-a-release

To build the text message now