Add semantic-release docs and call out caveats

[haani-niyaz]

semantic-release needs to be documented well. Specially the case where the first commit to master (as it is configured to act on master in our repo) will create release 1.0.0. Their convention varies as they claim 0.1.0 is not well defined and npm starts versioning at 1.0.0. However they provide pre-release guidelines:

https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/release-workflow/pre-releases.md

We need to make this explicitly clear to developers as this first release as 1.0.0 can come as a surprise. Ideally a working example should be provided.

The blog post they reference: https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2

Additionally, provide them with instructions for setting up tooling to follow commit message standards via https://commitizen-tools.github.io/commitizen/

[shukra-in-spirit]

It came as a surprise to me. I also expected 0.1.0. Can it be configured? For our purpose, the first minor version release might be better.

[haani-niyaz]

I looked but couldn't find anything 😔

[haani-niyaz]

Hmm I may have found something here: https://github.com/semantic-release/semantic-release/pull/532

Will test it out when I get a chance.

[haani-niyaz]

Ok looks like this can be fixed trivially if the first release is created manually (few clicks on the UI).

We can have instructions in the starter docs to create a pre release which also allows you set the tag i.e: 0.1.0. This forms the basis of all future increments so when semantic-release runs for a non-breaking change feature release it will detect that 0.1.0 exist and create the next tag/release of 0.2.0. To publish you just need to mark the commit as a breaking change which will increment it to 1.0.0.

Example pre-release setup:

[haani-niyaz]

Addressed in #30 .