DevKit updates

.github/ISSUE_TEMPLATE.md

@@ -48,5 +48,5 @@ $ php -v
     If it's an error message or piece of code, use code block tags,
     and make sure you provide the whole stack trace(s),
     not just the first error message you can see.
-    More details here: https://github.com/sonata-project/ecommerce/blob/2.x/CONTRIBUTING.md#issues
+    More details here: https://github.com/sonata-project/ecommerce/blob/3.x/CONTRIBUTING.md#issues
 -->

.github/ISSUE_TEMPLATE/Bug.md

@@ -54,5 +54,5 @@ $ php -v
     If it's an error message or piece of code, use code block tags,
     and make sure you provide the whole stack trace(s),
     not just the first error message you can see.
-    More details here: https://github.com/sonata-project/ecommerce/blob/2.x/CONTRIBUTING.md#issues
+    More details here: https://github.com/sonata-project/ecommerce/blob/3.x/CONTRIBUTING.md#issues
 -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -6,9 +6,9 @@
 <!--
     Show us you choose the right branch.
     Different branches are used for different things :
-    - 2.x is for everything backwards compatible, like patches, features and deprecation notices
+    - 3.x is for everything backwards compatible, like patches, features and deprecation notices
     - master is for deprecation removals and other changes that cannot be done without a BC-break
-    More details here: https://github.com/sonata-project/ecommerce/blob/2.x/CONTRIBUTING.md#the-base-branch
+    More details here: https://github.com/sonata-project/ecommerce/blob/3.x/CONTRIBUTING.md#the-base-branch
 -->
 I am targeting this branch, because {reason}.
 

.travis.yml

@@ -5,7 +5,7 @@
 branches:
   only:
     - master
-    - 2.x
+    - 3.x
 
 language: php
 

CONTRIBUTING.md

@@ -208,15 +208,15 @@ Here is a short table resuming on which you have to start:
 
 Kind of modification | Backward Compatible (BC) | Type of release | Branch to target        | Label |
 -------------------- | ------------------------ | --------------- | ----------------------- | ----- |
-Bug fixes            | Yes                      | Patch           | `2.x`   | |
+Bug fixes            | Yes                      | Patch           | `3.x`   | |
 Bug fixes            | No (Only if no choice)   | Major           | `master` | |
-Feature              | Yes                      | Minor           | `2.x`   | |
+Feature              | Yes                      | Minor           | `3.x`   | |
 Feature              | No (Only if no choice)   | Major           | `master` | |
-Deprecation          | Yes (Have to)            | Minor           | `2.x`   | |
+Deprecation          | Yes (Have to)            | Minor           | `3.x`   | |
 Deprecation removal  | No (Can't be)            | Major           | `master` | |
 
 Notes:
-  * Branch `2.x` is the branch of the **latest stable** minor release and
+  * Branch `3.x` is the branch of the **latest stable** minor release and
   has to be used for Backward compatible PRs.
   * If you PR is not **Backward Compatible** but can be, it **must** be:
     * Changing a function/method signature? Prefer create a new one and deprecate the old one.
@@ -683,7 +683,7 @@ Before releasing anything, it is best to reduce the gap between branches:
 
 Before abandoning it, the legacy branch MUST receive a last patch version.
 Likewise, the stable branch MUST receive a last version if that version is minor,
-it SHOULD receive one is that version is a patch version.
+it SHOULD receive one if that version is a patch version.
 
 #### Creating the new stable branch and files