docs: improve gitflow model for supported versions

Currently, supported versions are hosted on `support/<version>`. This bramch is intended to receive all commits and pull requests for compatible patches in order to prepare a release. The release would be made on the same bramch.

The issue with this model is that unline latest versions, support versions are not released on a "safe" branch. In order to resolve this issue and harmonize the way versions are prepared and released, the current commit move `support/<version>` to `develop/<version>` and add `master/<version>`.

Changes:
* Update CONTRIBUTING documentation to describe the `develop/...`+`master/...` approach
* Update GitHub pull request template to advise `develop/...` instead

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 0436a81c977496e516b86a7e8dac9663e094058a..51d9bc3adc567a52e6a13af088b3ed1293ebbf06 100644 (file)
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -35,7 +35,7 @@
 - [ ] There are no other pull request similar to this one.
 - [ ] The pull request title is descriptive.
 - [ ] The template is fully and correctly filled.
-- [ ] The pull request targets the right branch (`develop` or `support/*`).
+- [ ] The pull request targets the right branch (`develop` or `develop/v...`).
 - [ ] My commits are correctly titled and contain all relevant information.
 - [ ] My code follows the code style of this project.
 - [ ] I have updated the documentation accordingly to my changes (if relevant).

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1b84661cdccde94a82a385f32115eaf19e4eadec..41aa551acf6bdbd1c619f7c572a2a8a267c6e66c 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -55,27 +55,31 @@ After you made these checks, please follow these advices to create your pull req
 5. **Make sure that everything works and tests pass**.
    You must absolutely check that everything still works after your changes. Please also add tests for features you added or uncovered bugs you fixed. See the [Testing](https://github.com/zurb/foundation-sites#testing) section.
 6. **Create your pull request** ([link](https://github.com/zurb/foundation-sites/compare)).
-   Make sure it targets the right branch: most often `develop`, unless you provide a fix for an older version and it should be `support/*`. Take a look at our [Git Workflow](#git-workflow) below.
+   Make sure it targets the right branch: most often `develop`, unless you provide a fix for an older version and it should be `develop/v...`. Take a look at our [Git Workflow](#git-workflow) below.
 
 When you submit a pull request, @mention a few people you’d like to help you review it. Once those people have signed off on it, the pull request can be merged! Core Team members will handle the merge itself.
 
 ## Git Workflow
 
-Foundation uses a Git workflow close to the the successful [GitFlow](http://nvie.com/posts/a-successful-git-branching-model/) branching model, to which we added "support" branches to be able to release patches for older Foundation versions. Most of the time you will not have to care about this workflow and can simply open your pull request on `develop`.
+Foundation uses a Git workflow close to the the successful [GitFlow](http://nvie.com/posts/a-successful-git-branching-model/) branching model, to which we added `develop/v...` and `master/v...` branches to prepare and release patches for older Foundation versions. Most of the time you will not have to care about this workflow and can simply open your pull request on `develop`.
 
 The workflow relies on three branches:
 
-- **`master`**
+- **`develop`**
 
-  The stable branch. It only contains the latest stable version released. **Do NOT open pull requests on it**.
+  Used to prepare the next minor/major version. It always contains all the new features and bug fixes, and is the most up-to-date version of Foundation. Almost every pull request should be opened on this branch (fixes, features, documentation...). When a new version is released, it is merged on `master`, a dedicated `develop/v...` branch is created, and `develop` now targets the next version.
 
-- **`develop`**
+- **`develop/<version>`**
 
-  Used to prepare the next minor/major version. It always contains all the new features and bug fixes, and is the most up-to-date version of Foundation. Almost every pull request should be opened on this branch (fixes, features, documentation...). When a new version is released, it is merged on `master`, a support branch is created, and `develop` now targets the next version.
+  Used to prepare patches for previous versions. For example: `develop/v6.5` to prepare the `v6.5.1` release. When a pull request for a bug fix is merged on `develop` and is compatible with supported versions, its commits must be added on the compatible `develop/v...` branches too. If a fix is not compatible with `develop`, a pull request can be opened on the latest compatible and supported `develop/v...` branch. When a new patch is released, it is merged on `master/v...` and `develop/v...` now targets the next patch for this minor version.
+
+- **`master`**
+
+  The stable branch. It only contains the latest stable version released. **Do NOT open pull requests on it**.
 
-- **`support/<version>`**
+- **`master/<version>`**
 
-  Used to support the previous versions (i.e. `support/v6.5` for `v6.5.0`) and prepare patches (i.e. `v6.5.1`). When a pull request for a bug fix is merged on `develop` and is compatible with supported versions, its commits must be added on the compatible `support/*` branches too. A patch version can be then released. If a fix is not compatible with `develop`, a pull request can be opened on the latest compatible and supported `support/*` branch.
+  The stable branch for previous versions. For example: `master/v6.5` for stable `v6.5.*` releases. **Do NOT open pull requests on it**.
 
 This git workflow was fully adopted as of `v6.5`, so `v6.4` and previous versions are not supported.