diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 82fba0f..6e42651 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -116,23 +116,34 @@ and the final version are only comitted and tagged in this branch. The master br
 development versions, allowing us to keep the branches completely separate without merging releases
 back into master.
 
-The exact steps for an exemplary `1.2.3` release might look like this:
- 1. Initially, the version on the latest master is `1.2.3-dev`
- 2. A new `v1.2.3` branch is created for the release
- 3. On master, the version is bumped to `1.2.4-dev`
- 4. In the branch, the version is bumped to `1.2.3-rc1`
- 5. The new commit in the branch is tagged as `v1.2.3-rc1`
- 6. A GitHub release is created for the `v1.2.3-rc1` tag
- 7. The changelog since the last release (stable or RC)
-        is added to the GitHub release description
- 8. Bug fixes are cherry-picked from master into the branch and steps 4-7
-        are repeated until no major issues are found in the release candidates
- 9. In the branch, the version is bumped to `1.2.3`
- 10. The new commit in the branch is tagged as `v1.2.3`
- 11. A GitHub release is created for the `v1.2.3` tag
- 12. The changelog since the last stable release (**not** RC)
-        is added to the GitHub release description
- 13. The `-dev` is stripped from previous changelog entries
+The exact steps for an exemplary `0.2.0` release might look like this:
+  1. Initially, the version on the latest master is `0.2.0-dev`
+  2. A new `v0.2.0` branch is created for the release
+  3. On master, the version is bumped to `0.3.0-dev`
+  4. In the branch, the version is bumped to `0.2.0-rc1`
+  5. The new commit in the branch is tagged as `v0.2.0-rc1`
+  6. A GitHub release is created for the `v0.2.0-rc1` tag
+  7. The changelog since the last release (stable or RC) is added to the GitHub release description
+  8. Bug fixes are cherry-picked from master into the branch and steps 4-7 are repeated until no
+     major issues are found in the release candidates
+  9. In the branch, the version is bumped to `0.2.0`
+ 10. The new commit in the branch is tagged as `v0.2.0`
+ 11. A GitHub release is created for the `v0.2.0` tag
+ 12. The changelog since the last stable release (**not** RC) is added to the GitHub release
+     description
+ 13. The `-dev` is stripped from the `0.2.0-dev` changelog entries on master
+
+On master and with new planned releases, only the minor version is bumped. This makes it possible to
+create bug fix releases by incrementing the patch version of a previous minor release, without
+having to adjust the next planned release's version number.
+
+The exact steps for an exemplary `0.2.3` release might look like this:
+ 1. Initially, the version on the latest master is `0.3.0-dev` and the latest release was `0.2.2`
+ 2. A new `v0.2.3` branch is forked from the `v0.2.2` branch
+ 4. All bug fixes are cherry-picked from master into the `v0.2.3` branch
+ 5. The version is bumped to `v0.2.3-rc1` and the changelog is updated to include all fixes
+ 6. Follow Steps 5-12 of the regular release's example
+ 7. The release's changelog is ported back to master, removing fixes from the `0.2.3` release
 
 # Contact