Semantic release

[afontcu]

This PR closes #81.

This is just a draft PR to explore semantic-release and commitizen.

Tools:
https://github.com/semantic-release/semantic-release
https://github.com/commitizen/cz-cli

I've following semantic-release getting started guide, and also the "official" config for Travis. Also this tutorial came in handy.

I'm having a hard time getting a --dry-run execution to successfully perform all the required steps. I've used my account to provide tokens for both GitHub and npm, but got no luck when testing it out:

it might be due to running it before having everything in place on master, but I was hoping I could test it out before merging anything.

[afontcu]

With the current implementation, git commit would trigger commitizen, so any contributor would be able to set the appropriate commit message.

[afontcu]

I'm wondering if we should use kcd-scripts to avoid the hassle 🤔

[afontcu]

Build failed due to commitizen only supporting node >= 10.

[dfcook]

This looks like it's using https to make the push (asking for username and password) not your token.

I'm wondering if we should use kcd-scripts to avoid the hassle 🤔

Are they easy enough to use? Anything that gives consistency with other testing libraries is a good think IMO.

[afontcu]

This looks like it's using https to make the push (asking for username and password) not your token.

It is weird, though, because it created the appropriate GH token, and there's no cli option to push using SSH instead of https (docs).

[afontcu]

I'm wondering if we should use kcd-scripts to avoid the hassle 🤔

Gave it a go in #86

[afontcu]

I like Kent's idea of avoiding commitizen and switching to a squash&merge strategy instead (we could disable all merging strategies on the repo) so that we are responsible for writing the right commit message.

[afontcu]

Closing in favor of #86