This page is an ongoing effort to document current release process, gather important discussions points from the dev mailing list and progress toward a fully fledged release procedure with as much automation as possible.

Infrastructure notes

Since we are using git for version control there are a few caveats that have to be considered in defining the release process:

• git is distributed and ​does not keep a linear history like centralised VCS;
• pretty much ​everithing is considered a branch;
• there is a ​successful git branching model out there that we can draw upon.

Versioning scheme

Versions are numbered according to ​semantic versioning (we may reference the fields X.Y.Z as M.m.p to better indicate Major, minor and patch numbering), starting with 8.4.0. Tentative interface definition is defined by the standards supported in the features matrix and the command line tools parameters.

Initial process

A single main repository is maintained (as we already have).

The repository contains two types of branches on it:

• master (single instance) — the currently available branch, which will be the main development branch;
• release (mulitple instances) — When starting release process (consolidation of beta, rc, and other testing releases), a release branch is created with name release_M.m. These branches will allow maintenance of past releases, while development continues in the master branch.
  • Where M=Major version; m=minor version; All patch versions will belong to the same "minor" branch
    • Note: consider broader detail such as per-major version release line (fewer branches) or cleaning up branches for un-maintained versions

As an example consider release 8.4.0 and following bugfixes and regression pathces:

   release_8.4 (branch)
  /tag v8.4.0 ------ P ---- P* -- P---------->  tag v8.4.1 ------- P* ---- P ------->  tag v8.4.2
 /                    \            \
master (branch)        \            \
-- F -- F ------ F  --- P -----------P-- (until time comes for a new release (either 8.5 or 9.0)
  
P = bugfix/regression  ; P* = bugfix not applicable to master (due to new features) ; F = new feature development

A local branch can be checked out and with recent versions of git also a remote one with the same name:

git checkout release_M.m

#should give you output similar to:
Branch release_M.m set up to track remote branch release_M.m from origin.
Switched to a new branch 'release_M.m'

Note that branches on the main repository are remote branches that, if not automatically tracked on checkout as above, might need a specific ​checkout procedure to be worked with.

NOTE: Is there a way to "export" a tag directly from a remote git repo? This will save users from getting all the clone to just test a beta or rc. We provide source tarballs for that meanwhile.

Every release, both testing (cleaned up afterwards) and final, is marked by a tag according to the pattern vM.m.p (we are keeping the "v" prefix for historical reasons) in the repo, which can be checked out with

git checkout vM.m.p

Releases can only be made if the ​build status is successful for the latest commit.

Open issues

Testing time

We should estabilish some time frame to advance in the release process: now we wait one week before advancing -rc if bugfixes come in.

Patch manager with branches

Patch manager will be updated to support the branching model.

Tags

Do tags belong to a branch or are they still visible repository wide on git?

• Looks like tags are still repository wide, need to be tested with tags on remote branches.