Add release.yml to define changelog format for releases

[alexhung]

Closes #83

Per https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes

[TJM]

We should probably have a breaking change category, although I would hope we don't have to use it.

[alexhung]

The thing I don't necessary like about this approach is that it relies on the PR author/reviewer to ensure the labeling is applied.

[TJM]

The thing I don't necessary like about this approach is that it relies on the PR author/reviewer to ensure the labeling is applied.

Agreed, it is about the same as depending on the "conventional" commit messages to automatically determine the major/minor/patch. Either way, a human decides what the next version number will be based on the label. I am not sure if there is a way to prevent merges if there are NO labels :-/

I wonder if there is some way to "parse" all the handlers and auto-generate an "API" of sorts, that we could compare to a previously released version, then determine "programmatically" whether it was a patch, new feature or breaking change? We tried to do that in our terraform, but I always wonder whether it is missing things :) Frankly, I think that is putting too much effort into release management, unless there is something that hashicorp uses that we could reuse.

[alexhung]

I am not sure if there is a way to prevent merges if there are NO labels :-/

There's no branch protection settings in GitHub to prevent that. We can add another PR status check to the list, in theory.