From f396448d9d2b7fddd61f7ae139a7912ff473b18c Mon Sep 17 00:00:00 2001 From: Jascha Franklin-Hodge Date: Mon, 18 Mar 2019 15:47:07 -0400 Subject: [PATCH] Swapped position of Branch Mechanics and Release Process --- ReleaseGuidelines.md | 57 ++++++++++++++++++++++---------------------- 1 file changed, 29 insertions(+), 28 deletions(-) diff --git a/ReleaseGuidelines.md b/ReleaseGuidelines.md index 25a7b89f..ee8fccc7 100644 --- a/ReleaseGuidelines.md +++ b/ReleaseGuidelines.md @@ -5,12 +5,12 @@ MDS will see regular updates and new [releases][mds-releases]. This document des ## Table of Contents * [Versioning](#versioning) -* [Branch Mechanics](#branch-mechanics) * [Release Process](#process) * [Goals](#goals) * [Roles](#roles) * [Schedule](#schedule) * [Communication and Workflow](#communication-and-workflow) + * [Branch Mechanics](#branch-mechanics) * [Checklist](#release-checklist) ## Versioning @@ -25,33 +25,6 @@ At this early stage, MDS will be moving relatively quickly with an eye toward st For now, MDS will maintain *two concurrent (MINOR) versions* (e.g. if `0.3.0` were the current version, the `0.2.x` series would continue to receive maintenance in addition to `0.3.x`). -## Branch Mechanics - -Aside from using `git tags` as mentioned earlier, here we outline a branching strategy to handle ongoing maintenance changes in parallel with features for new releases. - -### Primary branches - -At a high-level, there are two primary branches: - -* [`master`][mds-master] represents the current stable release (i.e. the most recent tag) of MDS. Development work generally *does not* happen here, but is rather merged from elsewhere. - -* [`dev`][mds-dev] represents work on the next MINOR release, and is the *long-term* development branch. - -### Feature branches - -Work on new features for MDS happens in branches cut from `dev`. When the feature is ready for review, submit a PR against `dev`, ideally with any merge conflicts already resolved. `dev` serves as the collection point for all new feature work. - -### Release branches - -In anticipation of ongoing maintenance, a branch will be created for the current release series. For example, at the time `0.2.0` is released, a branch will be cut from `master` for `0.2.x`. - -This *release branch* represents the current state of that release series. All maintenance/bugfix work for the series is collected in this branch. To work on a patch, cut a branch from the release branch. When ready, submit a PR against the release branch. - -When a PATCH release is ready (e.g. `0.2.0` to `0.2.1`), the release branch (e.g. `0.2.x`) is merged to `master` (to make the release official) and `dev` is rebased onto `master` (to ensure the patch is incorporated with any new work). - -Breaking changes should always be merged to develop. These may be merged at any time and will be incorporated into the next minor release. For non-breaking changes, these should either be merged to develop if the next release is a minor release, or to the appropriate release branch if the next version is a patch release. During each cycle, we merge changes to both dev and 0.n.x branches, so breaking changes can be proposed and worked on at any time - -As stated earlier, at this time MDS will maintain *two concurrent MINOR versions*. This means that when a MINOR release is made (e.g. `0.4.0`), work on the outgoing series (`0.2.x`, in this case) ceases and its release branch is removed. ## Release Process The sections below define the release process itself, including timeline, roles, and communication best practices. @@ -115,6 +88,34 @@ The following best practices are intended to create clarity around each release * Proposed changes should come in the form of PRs to give the community ample awareness and time for feedback +## Branch Mechanics + +Aside from using `git tags` as mentioned earlier, here we outline a branching strategy to handle ongoing maintenance changes in parallel with features for new releases. + +### Primary branches + +At a high-level, there are two primary branches: + +* [`master`][mds-master] represents the current stable release (i.e. the most recent tag) of MDS. Development work generally *does not* happen here, but is rather merged from elsewhere. + +* [`dev`][mds-dev] represents work on the next MINOR release, and is the *long-term* development branch. + +### Feature branches + +Work on new features for MDS happens in branches cut from `dev`. When the feature is ready for review, submit a PR against `dev`, ideally with any merge conflicts already resolved. `dev` serves as the collection point for all new feature work. + +### Release branches + +In anticipation of ongoing maintenance, a branch will be created for the current release series. For example, at the time `0.2.0` is released, a branch will be cut from `master` for `0.2.x`. + +This *release branch* represents the current state of that release series. All maintenance/bugfix work for the series is collected in this branch. To work on a patch, cut a branch from the release branch. When ready, submit a PR against the release branch. + +When a PATCH release is ready (e.g. `0.2.0` to `0.2.1`), the release branch (e.g. `0.2.x`) is merged to `master` (to make the release official) and `dev` is rebased onto `master` (to ensure the patch is incorporated with any new work). + +Breaking changes should always be merged to develop. These may be merged at any time and will be incorporated into the next minor release. For non-breaking changes, these should either be merged to develop if the next release is a minor release, or to the appropriate release branch if the next version is a patch release. During each cycle, we merge changes to both dev and 0.n.x branches, so breaking changes can be proposed and worked on at any time + +As stated earlier, at this time MDS will maintain *two concurrent MINOR versions*. This means that when a MINOR release is made (e.g. `0.4.0`), work on the outgoing series (`0.2.x`, in this case) ceases and its release branch is removed. + ## Release Checklist The following steps **must** be followed for **every** release of MDS: