From bc1aff343f79d0523d471fd8f2f704ba7d77ef96 Mon Sep 17 00:00:00 2001 From: Johan Wikman Date: Mon, 4 Jun 2018 11:02:31 +0300 Subject: [PATCH] Add document on branching and tagging Easier to ensure it stays up to date if it is kept among the source rather than in the GitHub wiki-page or the intranet. --- Development/branching-and-tagging.md | 118 +++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 Development/branching-and-tagging.md diff --git a/Development/branching-and-tagging.md b/Development/branching-and-tagging.md new file mode 100644 index 000000000..77227bb83 --- /dev/null +++ b/Development/branching-and-tagging.md @@ -0,0 +1,118 @@ +# Branching and Tagging + +## Overview + +This document describes how git branches and tags are used in the MaxScale +development. + +## Releases + +The releases of MaxScale are numbered as `X.Y.Z` where `X` denotes the +major version (currently is `2` and changes very rarely), where `Y` denotes +the minor version (when changed, implies the introduction of new features), +and where `Z` denotes the maintenance version (when changed, implies that +bugs have been fixed). + +When `X` changes, `Y` is reset to 0 and when `Y` changes, `Z` is reset to +0. + +## Branches + +## Two kinds + +There are two kinds of minor branches in MaxScale; branches named as +`X.Y`, such as `2.1` and `2.2` and the branch `develop`. + +The development of the _next_ minor release takes place in `develop`. + +The only development that takes place in an `X.Z` branch are development +related to bug fixes. Occasionally, due to explicit customer demand, +feature development may also take place. + +## Maintenance Releases + +Suppose the last released version is `2.1.6`. + +Any bug fixes related to version `2.1.6` are now pushed to `2.1`. When +there are "enough" bug fixes, or at least one and enough time has passed +since the last release, a new tag is created. +``` +git checkout 2.1 +git tag -a maxscale-2.1.7-tt1 +git push --tags origin +``` +The suffix `-tt1` stands for _tentative tag 1_, because before the +test-suite has been run and all packages have been built (using that tag), +we do not know with certainty whether that commit actually will be the +release `2.1.7`. + +If there are problems, then those are fixed and a new tag +`maxscale-2.1.7-tt2` is created. That continues until there are no issues +left. Typically a few iterations are needed. + +Once all is green, the final tag is created. +``` +git checkout maxscale-2.1.7-tt2` +git tag -a maxscale-2.1.7 +``` +but the packages are not rebuilt. At this point, the tentative tags are +removed: +``` +git tag -d maxscale-2.1.7-tt1 +git tag -d maxscale-2.1.7-tt2 +git push origin :refs/tags/maxscale-2.1.7-tt1 +git push origin :refs/tags/maxscale-2.1.7-tt2 +``` +At this point, the _branch_ `2.1.7` is also created: +``` +git checkout maxscale-2.1.7 +git checkout -b 2.1.7 +git push origin 2.1.7 +``` +This branch is **only** used for updating the documentation, if there is +an urgent need for doing that. There is always one need; once the packages +have been uploaded to the download site and we know the exact date when +they will be made available, the release date is added in the release notes. +``` +git checkout 2.1.7 +# Update the release date +git add Documentation/Release-Notes/MaxScale-2.1.7-Release-Notes.md +git commit +git push origin 2.1.7 +``` +The next step is to merge that branch into the corresponding minor branch. +``` +git checkout 2.1 +git merge 2.1.7 +``` +Now the updated minor branch should be merged upwards until we reach +`develop`. +``` +git checkout 2.2 +git merge 2.1 +git checkout develop +git merge 2.2 +``` + +## Feature Releases + +Feature releases are always the next minor version and the development +takes place in `develop`. + +The procedure is roughly similar to that releated to maintenance releases +but with an inital deviation. + +Once the development of the next minor release is close to readiness, the +new minor release branch is created. +``` +git checkout develop +git checkout -b 2.3 +git push origin 2.3 +``` +After this, all commits related to the next release, are pushed to the +branch `2.3`. If there already is development related to the minor release +following that, those commits are pushed to `develop`. + +Hereafter the procedure is exactly like the one of a maintenance +release. The first tag will be `maxscale-2.3.0-tt1`, the final tag will be +`maxscale-2.3.0` and the branch `2.3.0`.