Bugzilla:Release Process

Bugzilla Releases

Version Numbers

Major version increases (e.g. 5.0) reflect large, visible, and/or breaking changes. These would include features being removed, interfaces being changed, dependencies being updated, significant UI changes, major new features, etc.

Minor version increases (e.g. 5.2) reflect noncritical bugfixes, small new features, and other nonbreaking changes. These would include additions and/or backward-compatible changes to interfaces, support for new technologies or platforms, and general improvements and fixes. Note that official releases will always have an even-numbered minor version (e.g. 5.0, 5.2, 5.4); odd numbers are reserved for development releases. This applies only to the minor version number.

Patch version increases (e.g. 5.2.1) reflect critical fixes, such as to security or other severe bugs. While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime.

When to Release

In May 2014 we decided to try to release approximately every 6 months with whatever is ready at the time. This gets new features out the door more quickly. Branching should be done when master is relatively stable, but sometimes branching with known bugs is acceptable if it allows other large, potentially unstable features to land (for the next release). If there are bugs related to new features in the release branch, the feature should be backed out of the release branch (if it's very recent), or fixes should be committed to both the release branch and master. Bugs blocking release should be denoted with a blocking<version> flag, e.g. blocking5.0.

The version number will be determined at time of branching depending on the changes included, as per the section above. Note that this means we may have back-to-back major releases.

What to Release

As stated above, generally master will be branched approximately six months after the previous release, but there may be additional bugs to be fixed. In August 2014, at the public meeting and follow-up newsgroup discussion we decided that the Target Milestone should be used to denote things that should be fixed before release, i.e., blockers, or bugs being actively worked on. Release candidates should only be created after there are zero open bugs with the Target Milestone set to that release. Furthermore, only the bug's assignee or a Bugzilla reviewer/approver should set or unset the Target Milestone.

The existing policy of having approvers set or update the Target Milestone, if necessary, on bugs that are committed before an upcoming release continues unchanged.

Release Process Details

...