Use pull request #11378 from ncoden/docs/improve-gitflow-model-for-supported-versions...

86a0aaef9 docs: improve gitflow model for supported versions
4ed00bf51 docs: use valid branch names for supported versions

Signed-off-by: Nicolas Coden <nicolas@ncoden.fr>

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 0436a81c977496e516b86a7e8dac9663e094058a..11fe5c0179c6ee16503b8be928ad15411324fe9a 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..332503546d80a8a660b9d792937c471352b0ea76 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.