Consider using semantic-release

[bmullan91]

Notes

• commits will need to follow a certain format fix, feat or BREAKING CHANGE
• semantic-release figures out what the new version should be
• generates release notes
• generates git tag
• publish the new release

see https://github.com/semantic-release/semantic-release for more info.

[jackdclark]

@bmullan91 I've been investigating this one this morning.

Lerna supports the conventional commit spec via config or a --conventional-commits flag. When run with this flag, lerna version will use the spec to determine the version bump and generate CHANGELOG.md files.

Lerna also has a --github-release flag - which, when used with --conventional-commits, will create an official GitHub release based on the changed packages.

As we already follow a squash based workflow on this project when merging PRs, it wouldn't be much overhead to enforce us as maintainers to use conventional commits when merging PRs & we'll then get all of the above. It also means we wouldn't have to force contributors to follow the spec when raising PRs, which could be off-putting if they have to follow too much process. (See Do all my contributors need to use the conventional commit specification?)

Thoughts @bmullan91 @Joezo?