This document describes the release process Pootle follows starting from version 2.5.
The principles above extended into these rules.
A Pootle version number consists of Major-Minor-Point-Bugfix
as in
2.5.0
or 2.6.1.2
Pootle’s minor number is changed to indicate the latest version of Django that is supported. Thus when the latest version of Django is released, and Pootle gains support for this version, then the Pootle minor number will change.
Note
Pootle 2.5.0 is an exception to this rule. It did not support Django 1.5 at the time of release.
Every six months, when a new release train is ready to be shipped, Pootle’s point version will be incremented.
Any critical security fixes will automatically result in a new bugfix release.
Understanding the number and release train with some examples:
Django 1.5 is the latest version of Django:
2.5
and should support Django 1.5.2.5.0
is released as the first time-based release.2.5.1
.A security issue is detected in Pootle 2.5.0
2.5.0.1
is made2.5.1
Django 1.6 is released:
2.5.4
, next Pootle release will be 2.6.0
2.6.0
is out we will support Pootle 2.6.0
and 2.5.4
, all
previous versions will be unsupported.A security issue is discovered which impacts all our supported time-based releases:
2.6.0.1
and 2.5.4.1
Time-based release 2.6.1
is released six months after 2.6.0
2.6.1
and 2.6.0
2.5.4
which is now a year old.Within the priciple that master is always deployable we aim to ensure a period of stability to allow easier release in the month prior to a time-based release.
If for some reason there’s feature work that changes the schema during month six of the release train, the feature will go in its own branch and won’t be merged until the next release train starts.
Security fixes are applied anytime in the release train.
The next Pootle version is always baked in the master branch. Exceptions are security fixes which are committed in master and cherry-picked to the currently supported time-based release branches.
A new time-based release is made off of master, incrementing the point
version. Every time a new release happens, a new branch is created. These
branches are named after their version numbers: if master is to become
version 2.6.2
, then the new branch will be named stable/2.6.2. The actual
release is also tagged, in this case as 2.6.2.
Security fixes are made on the relevant release branches. So the first security release on stable/2.6.2 would be tagged as 2.6.2.1.
Features that produce schema changes or are quite invasive go into feature branches named feature/<feature-name>. Once the feature is ready to be integrated within the first phase of the release train, they’re merged into master.