release-please

[JonathanWoollett-Light]

Adds release-please automation.

• release-please: Automatically updates the SemVer version, creates a PR for each release (people don't need to manually edit the changelog) when merged adds the release tag. This can be expanded to incorporate other functionality later (e.g. publishing to crates.io).
• gitlint: Enforce conventional commits required by release-please

See JonathanWoollett-Light#1

[asomers]

What does this do?

[JonathanWoollett-Light]

What does this do?

Added some more information, the effects can be seen on my fork.

[asomers]

cargo-release already takes care of editting the Changelog for us. I'm not sure how much extra value release-please provides.

[JonathanWoollett-Light]

cargo-release still requires every commit to manually edit the changelog does it not?

Also notablty:

cargo-release's versioning tracks compatibility for the binaries, not the API.

Which would indicate the SemVer doesn't work in this instance?

[asomers]

Yes it does. Does release-please generate the changelog based on commit messages instead?

[JonathanWoollett-Light]

Yes it does. Does release-please generate the changelog based on commit messages instead?

Yes it generates it based on the commit message. See the PR I linked above (JonathanWoollett-Light#1) which shows the automatically generated PR to the change.

[rtzoeller]

This might remove the requirement that maintainers be able to push directly to master in order to publish releases, which is appealing.

Changelog management is definitely an issue today, but I do really value having a centralized changelog file in the repo. That may not be a hard-requirement though. I'd be curious if there is a way to preview the release-please changelog for a release before publishing, to make sure you're happy with how it comes out - it'd be annoying to miss something just because a commit was formatted incorrectly.

[JonathanWoollett-Light]

Changelog management is definitely an issue today, but I do really value having a centralized changelog file in the repo.

The PR it generates just appends to changelog.md so it is still centralized.

I'd be curious if there is a way to preview the release-please changelog for a release before publishing

You can see the changes in the PR it generates and maintains, this is only a base so you could take this then expand upon it with manual additions.

[JonathanWoollett-Light]

@rtzoeller @asomers Rebased and re-ran CI, could you please review/can we get this merged?

[SteveLauC]

Some thoughts on this thing:

1. release-please generates CHANGELOG from commit message, which requires that commit message should be semantic

   Not everyone is a fan of this stuff, you can see this from nix's commit history (However, I am)

2. In our CHANGELOG, we have 4 types of logs:

   1. Added
   2. Changed
   3. Fixed
   4. Removed

   Their corresponding semantic commit message types would be

   nix change log type	commit msg type
   Added	feat
   Changed	refactor
   Fixed	fix
   Removed	refactor

   You can see that both Changed and Removed would use refactor here,
   which means we cannot distinguish them when generating CHANGELOGs using
   release-please.

   This seems to be customizable, but needs some work I guess

3. The generated CHANGELOG:

   * I/O safety for 'kmod' 
     ([2f546c9](https://github.com/JonathanWoollett-Light/nix/commit/2f546c98cb1abb4463f13b084443ae4bf1597cb3)) 
   

   has a link to that commit instead of PR, honestly, I prefer PR more as I can
   see the discussion/context of how people were working on it.

   Still, should be customizable, but needs some work

4. When we switch to towncrier, the management of CHANGELOG would be much easier

5. From this comment:

   This might remove the requirement that maintainers be able to push directly
   to master in order to publish releases, which is appealing.

   This is indeed appealing