diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1778a15d8af7023df424cd46cada0795fe20d47c..f4af687d603dbd393acd3b93369b7e578d39aea2 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -70,7 +70,7 @@ Please note we have a specific workflow, please follow it in all your interactio
 
       It forces you to write documentation for any public code and prevent you from using unstable
       or unsafe code.
-      
+
   1.  Write unit tests, and verify that they **all** pass.
   1.  Made a git rebase to make your history clean.
 
@@ -83,11 +83,25 @@ Please note we have a specific workflow, please follow it in all your interactio
 
 ## Merge Process
 
-1. Ensure any install or build dependencies are removed before the end of the layer when doing a 
-   build.
-2. Update the README.md with details of changes to the interface, this includes new environment 
-   variables, exposed ports, useful file locations and container parameters.
-3. Increase the version numbers in any examples files and the README.md to the new version that this
-   Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
-4. You may merge the Merge Request in once you have the sign-off of two other developers, or if you 
-   do not have permission to do that, you may request the second reviewer to merge it for you.
\ No newline at end of file
+1.  Ensure any install or build dependencies are removed before the end of the layer when doing a 
+    build.
+
+1.  Ensure you rebased your branch on the latest `dev` commit to avoid any merge conflicts.
+
+1.  Update the README.md with details of changes to the interface, this includes new environment 
+    variables, exposed ports, useful file locations and container parameters.
+
+1.  Increase the version numbers in any examples files and the README.md to the new version that this
+    Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/) :
+
+    If the create is in developement stage, its format is 0.X.Y. In production stage, it's X.Y.Z.
+
+    - When a API breaking change is made, X must be incremented.
+    - If new features are added without breaking the API, Y must be incremented.
+    - If the change is a quick fix of a production version, Z is incremented.
+
+    Your crate should always start with 0.1.0 version and only pass in 1.0.0 when no big changes are
+    planned. There is no need to rush a 1.0.0, take your time :)
+
+1.  You may merge the Merge Request in once you have the sign-off of two other developers. If you 
+    do not have permission to do that, you may request the second reviewer to merge it for you.
\ No newline at end of file