Semantic Release?

[mikeal]

Got linked to this by @janl and it looks like it would be pretty great.

https://github.com/boennemann/semantic-release/

[simov]

I kind of like the idea of automating the release process, although the 'release on every push' approach sounds a bit radical at first.

configure your CI server to release only on the production/deploy/release branch and push your code there in certain intervals

In this case which commit message will be taken to generate the release number?

I'm not familiar with the Angular's git commit message convention or any other, but I'm wondering how we're going to employ that convention across possibly completely random contributors?

[janl]

configure your CI server to release only on the production/deploy/release branch and push your code there in certain intervals

In this case which commit message will be taken to generate the release number?

The most significant, a breaking change commit message will bump the major version number, a feature commit message will bump the minor version number and a fix message will bump the patch version. If you have a feature and a fix, you get a new minor version number.

I'm not familiar with the Angular's git commit message convention or any other, but I'm wondering how we're going to employ that convention across possibly completely random contributors?

We handle this with a clear CONTRIBUTING.md that explains the format. Angular’s is pretty straightforward, but semantic-release is built so you can hook indoor own commit message analysers, if you like a different flavour. A little more legwork required, but doable. You will, however, have to conform to a specific format, a PR-analyse robot could auto-flag non-matching commit messages.

If you have any more questions, ping me or @boennemann :)

[boennemann]

Thanks for putting this up for discussion @mikeal 👍

@simov
1.

In this case which commit message will be taken to generate the release number?

It's not using the latest commit message, but every message since the last release (or all if no release yet). So if you decide to go for a publish-branch workflow it would take all changes into account and then go with the highest increase type (major, minor, patch, null) it can find.

I can totally understand why you're worried about contributors adhering to this certain style, but I think the fact that Angular successfully applied it to all their projects shows that it's doable.
As @janl said you have to communicate e.g. via CONTRIBUTING.md and ask your contributors to rewrite some messages at times. You could also rebase the changes onto master and rewrite the messages to match the style yourself, but that should be an exception.

All in all it certainly takes some time until everyone is accustomed to this, but I think given how good the changelog that comes out of it is and the other easements semantic-release gives you it's worth it.

Also semantic-release offers a verification hook that runs directly before the actual publish happens and we're currently using it for breaking change detection (Runs the testsuite of the latest release against the current versions and sees if it breaks) ourselves, but you can come up with a lot more heuristics. A few ideas: release a new version only if at least x days have passed since the last one, don't release if coverage drops below a certain threshold, check dependencies for nodesecurity vulnerabilities and don't release if something is up, only release if every commit follows the commit conventions etc.

If there is something unclear or you need features I'm here for you :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.