build: provide automatic changelog generation (#7)

Signed-off-by: Dennis Heibült <mail@dennisheibuelt.com>

build: add .editorconfig

apart from the fact that an .editorconfig file is a good thing in
general, it is necessary now so we can create nested markdown lists.

docs: provide release guidelines

refactor: add extra changelog section for docs (#7)

because:
- it could benefit users who explicitly search the changelog for
documentation fixes or additions

this commit:
- adds a separate changelog section for documentation changes

refactor: extract changelog config to separate file (#7)

because:
- we want to keep a separation of concerns
- we want to keep things clear

this commit:
- creates a `.versionrc` file which contains all the changelog
config necessary for the `standard-version` package

build: use fixed versions for npm packages (#7)

because:
- we want the exact same dependencies on everyones machine and on the
build servers

this commit:
- sets the `save-exact=true` flag in `.npmrc`
- removes the `^` in front of every version number in the
`package.json`s dependencies.

BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to
definitely install the correct dependencies on your machine

.editorconfig

@@ -0,0 +1,12 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+indent_size = 4
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.md]
+trim_trailing_whitespace = false

.npmrc

@@ -0,0 +1 @@
+save-exact=true

.versionrc

@@ -0,0 +1,45 @@
+{
+    "releaseCommitMessageFormat": "release: {{currentTag}}",
+    "types": [
+        {
+            "type": "build",
+            "hidden": true
+        },
+        {
+            "type": "ci",
+            "hidden": true
+        },
+        {
+            "type": "docs",
+            "section": "Documentation"
+        },
+        {
+            "type": "feat",
+            "section": "Features"
+        },
+        {
+            "type": "fix",
+            "section": "Bug Fixes"
+        },
+        {
+            "type": "perf",
+            "hidden": true
+        },
+        {
+            "type": "refactor",
+            "hidden": true
+        },
+        {
+            "type": "release",
+            "hidden": true
+        },
+        {
+            "type": "style",
+            "hidden": true
+        },
+        {
+            "type": "test",
+            "hidden": true
+        }
+    ]
+}

CONTRIBUTING.md

@@ -101,3 +101,19 @@ this commit:
 When a pull request is approved, all the commits need to be [squashed](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) in a meaningful manner before the pull request is merged. That is, combining those commits that form a complete feature into **one commit**. That doesn’t necessarily mean that all the commits of every pull request should ever result in one single commit! For example, if a pull request provides a new feature but alongside this new feature, a bug was fixed, too, this would result in two sqashed commits: One for the feature and one for the bugfix. The aim of this practice is to produce a sensible fragmentation of commits so we can later automatically create our changelog from these commits.
 
 If you feel unsure about this process, just ping **[@fuhlig](https://github.com/fuhlig)** or **[@csshugs](https://github.com/csshugs)** in the comments of the pull request to request help. We’d love to do the squashing for you!
+
+## Release a new version
+
+The following workflow assumes that there are no redundant commits and evey relevant feature is represented with one commit only.
+
+1. Merge `develop` into `master` via GitHub pull request
+2. Check out `master` branch locally
+3. Run `npm run release`
+4. Check `CHANGELOG.md` and fix content if necessary   
+    4b. If `CHANGELOG.md` needed a manual change, run `git commit -a --amend --no-edit`
+5. Run `git push origin master`
+6. Run `git push --tags`
+7. Run `npm publish`
+8. Check out `develop` branch
+9. Run `git rebase master`
+10. Run `git push origin develop`