-
Notifications
You must be signed in to change notification settings - Fork 44
Release policy
This page describes when a release is made and how the contents of that release is decided. The practical step-by-step process of making a release is describe in another page.
The policy described here is based on input from Paul and Tigran. It hasn't been accepted formally, but no objections were raised when it was posted, so I think we can take it as a starting point to work with.
The project has one 'development branch' and one or more 'supported branches'.
In git, the development branch is called 'master' and the supported branches have names with two numbers joined by a '.'; for example, '2.0', '2.1'.
The development branch receives patches indefinitely.
[for discussion: pull-requests, commit rights, review-process, ...]
A new supported branch is made my creating a new branch from 'master' with the appropriate name.
[for discussion: when does this happen; who does this]
The supported branches receive patches for a fixed period.
[for discussion: how does code get into a supported branch]
When a supported branch is no longer supported then the branch is left as-is.
All patches are either a 'bug-fix' or 'new-development'. The decision is made by whoever is committing the patch (or accepting the pull request), but they may take into account comments from the patch's author.
A new-development patch is only committed to 'master'.
A bug-fix patch is applied to 'master' and merged from 'master' to each supported branch in decreasing order (most recently branched first). A supported branch is skipped only if the underlying bug is not present in that branch. If there are conflicts when merging the patch then the patch's author is responsible for providing an updated version of the patch targeted at that branch.
Each releases is made from a supported branch.
Releases from any branch are numbered consecutively. The first release is number '0'. The release name is derived by joining the name of the supported branch with a release number (e.g., '2.0' branch + release '5' => '2.0.5').
As part of the release process, a tag is created with the name of the release (e.g., '2.0.5'). This tag is never deleted.
All branches ('master' and all supported branches) strive to be "always releasable" --- no patch to any branch knowingly breaks that branch.
[for discussion: what happens when someone breaks a branch]