Release Process
The release process we follow is designed to fulfill the requirements to provide a sequence of high quality and stable releases on a regular basis (maintenance). At the same time it ensures that longer term development can take place (features and refactoring) without impacting the integrity of the stable releases.
To achieve this, there are always three (primary) tracks of development that are accessible from the GitHub repository.
Stable
The stable track is found on the master branch in the repository. This branch is only updated when either the maintenance or development track has reached a point of stability. This is the branch which is tagged with each released version, each one reflecting the complete set of changes between versions.
Maintenance
The maintenance track is used to apply bug fixes to the current stable version. This can be found on the maintenance branch in the repository. Changes to this branch follow a fixed schedule with the goal of providing a reliable and predictable sequence of stable maintenance versions after each major release. Only bug fixes are applied to this branch.
A maintenance cycle is started after every stable release. All available maintenance patches are applied on the first day of this cycle. Any subsequent maintenance patches are held until the start of the next cycle. The only patches applied to this branch during the cycle are regression patches that fix problems caused by the patches that were applied at the start. At the end of the cycle, changes to the maintenance branch are merged back into the master branch and a new stable release is created.
Release Frequency:
RCs (Release candidates) every 1-3 days
Stable versions every 2-4 weeks
(Nightly builds available)
Development
The development track is used for feature additions, refactoring, and bug fixes. This track is present on the development branch in the repository. Changes to this branch follow a more irregular schedule than those on the maintenance branch. The development allows users to access early feature releases with a basis for testing and the opportunity to provide feedback that shapes the direction of the development.
Patches are applied continuously during a development phase and are released in regular developer previews. Once the planned features have been implemented, the repository enters the release phase. Only regression patches are applied during this phase and released in regular release candidates. Once the repository is deemed stable, the changes are merged back into the master branch and a new stable release is created.
Release Frequency:
DPs (Developer previews) weekly during patch phase
RCs (Release candidates) every 1-3 days during release preparation phase
Stable versions released when they are ready
(Nightly builds available)
