Merge branch 'master' into feature/dynamic

Author: GeertvanHorrik

docs/git-branching-strategies/gitflow-examples.md

@@ -10,7 +10,7 @@ Feature branches will take the feature branch name and use that as the pre-relea
 
 Notice after the feature branch is merged, the version on `develop` is `1.3.0-alpha.3`. This is due to `develop` running in *continuous deployment* mode. If you configured `develop` to use *continuous delivery* the version would still be `1.3.0-alpha.1` and you would have to use release tags to increment the `alpha.1`.
 
-You can see the different on the feature branch itself, notice the version is the same before and after the commit on the feature branch? Only the metadata has changed. If you released the feature branch artifacts then tagged the commit, the following commit would increase to `-beta.2`.
+You can see the difference on the feature branch itself, notice the version is the same before and after the commit on the feature branch? Only the metadata has changed. If you released the feature branch artifacts then tagged the commit, the following commit would increase to `-beta.2`.
 
 ## Pull Request
 Because feature branches are most likely pushed to a fork, we are showing the

docs/reference/mainline-development.md

@@ -22,7 +22,7 @@ and the version number which will be deployed are often different.
 This mode is great if you do not want to tag each release because you simply
 deploy every commit to master. The behaviour of this mode is as follows:
 
-1. Calclate a base version (likely a tag in this mode)
+1. Calculate a base version (likely a tag in this mode)
 2. Walk all commits from the base version commit
 3. When a merge commit is found:
     - Calculate increments for each direct commit on master
@@ -54,4 +54,4 @@ change the [configuration](../configuration.md) as such:
 
 ```yaml
 mode: Mainline
-```
+```