Release Policy
From Habari Project
Habari has a policy to release often, meaning we plan several significant point releases each year. This page describes what can be expected from the different kinds of releases. See Release Checklist for specific information about the process of making a release.
Contents |
Major Releases
An example of a major release is 1.0. The release branch for a major release is a feature frozen branch and is created from trunk. The feature freeze should take place at least two weeks before release. A major version may introduce a new API, and therefore major versions may have incompatible APIs. Significant new functionality will be added in major releases. No guarantee is offered that plugins or themes will be compatible between major releases.
Major Point Releases
An example of a major point release is 0.4. The release branch for a major point release is a feature frozen branch created from trunk. The feature freeze should take place at least one week before release. Bug fixes and significant new functionality will be added in major point releases, but the API is compatible between major point releases. Plugins and themes should usually be compatible from one major point release to the next, but changes may be introduced that require modification to some plugins or themes.
Minor Point Releases
An example of a minor point release is 0.4.1, which would be a patch on the 0.4 release. The release branch for a minor release is created from its parent release tag. Branching should take place at least 48 hours before release. Minor point releases serve to correct issues that are considered critical to functionality of Habari from a user point of view. Examples of issues that may require a minor point release are:
- Issues that affect security, allowing unauthorized access to data, alteration of data, server or site compromise, cross-site scripting, or other similar vulnerabilities.
- Issues that result in loss of database data or user submitted data.
- Issues of existing released functionality that would otherwise be block a release.
Point releases should only be triggered by a specific issue relating to data loss, security, or critical functionality. Minor point releases may contain additional bug fixes unrelated to the issue that triggered the release. Examples of additional bug fixes that may be part of a point release include, but are not limited to, spelling corrections, CSS and style tweaks, removal of unused cruft, and other trivial or superficial items.
Except in the case of security issues, a minor point release should not affect the performance of plugins or themes. When possible, it is expected that attempts will be made to group multiple fixes into a single release.
There will always be a grey area about what makes an issue a critical issue. If you believe an issue warrants a minor point release, you should send an email to the developer mailing list, where a vote will be taken.
Release Series and Maintenance
The 0 Series
As there has not yet been a major release, Habari is currently in the 0 series of releases. Releases from 0.1 to 0.4 are intended for use by developers and are considered alpha releases. They're often called Developer Releases or DRs. Releases from 0.5 and before 1.0 are fit for use by normal users but at this point Habari should be considered beta software. Releases in the 0 series will not be maintained once a release has been superseded. For example, if 0.5 has been released and a bug is discovered that affects 0.4, a minor point release will not be made to 0.4.
Subsequent Series
After the 1.0 release Habari can be considered stable, production-ready software. We maintain the last major point version of the latest two major versions. So if we're at 7.3, then we also support 6.5, if there is no 6.6. At that point we would not support any of 5.x, no version of 6.x prior to 6.5, and no version of 7.x prior to 7.3. Users are expected to upgrade to the latest version of the major version they're using, since our maintenance will consist of applying changes as a new major or minor point release.
Release Procedure
Note: This procedure is still under development and subject to change. Once the Release Manager has determined that a new version of Habari is ready, they should post a message to the mailing list with a subject like [VOTE] X.X.X Release The vote should be left open for 48 hours (It is recommended to give ending time in YYYY-MM-DD format). Voting rules are as described on the Cabal page. All members of the Habari Community are permitted to vote, but non-PMC votes are considered advisory, rather than binding. When the voting period has elapsed, and the vote carries, the Release Manager should update the download files, publish a post to HP.o, and update the beacon.
Trunk, Tags, and Makaanga
The code in trunk is where most development happens, and as a result it is unstable. Development of new features shouldn't be hindered by the fact that there is an upcoming release. To allow development of trunk to continue and features to be frozen in preparation for release, testing and bug fixes occur in a release branch. Habari calls these release branches makaanga, a Swahili word meaning branches that bear fruit. When freezing for a major release, a makaanga named after the release series followed by an 'x' is created from trunk. When freezing a major point release, trunk is merged to the makaanga.
Changes Merged to the Makaanga
The aim of the makaanga is to create a stable release. Development continues as normal in trunk, with specific changes merged to the makaanga. To try to avoid the introduction of new bugs, merges into the makaanga should be conservative. The following process should be used to get consensus about what changes should be merged to a makaanga.
Once trunk has been merged into a makaanga, no new features should be added, but data loss and security issues, judged by the same criteria as for #Minor Point Releases, should be fixed, as should trivial or low impact bugs.
If there is any doubt or argument that the bug fits into the above categories, the fix shouldn't be included. This should be relaxed slightly if the feature being fixed has not previously appeared in a release.
When the makaanga is frozen, a member of the Habari community examines all open bugs and eliminates bugs that don't match the criteria above. The list of remaining issues is then sent to the developer mailing list for discussion, and where consensus to include cannot be reached, the issue is excluded from the release. New issues or bugs that are discovered during the feature freeze should be evaluated in the same way.
Tagging a Release
When the release branch is tested and stable, it should be tagged with the release number. Tags are stable snapshots of the Habari code. Once a tag has been created, no further development should happen to the code in the tag.
If issues arise that justify the release of a minor point release (see #Minor Point Releases), bug fixes and testing occur in the release branch. When stable, the release branch should then be tagged as the minor point release.
Tagging and Makaanga Examples
When freezing for 1.0 the makaanga 1.x is created. Once this is tested and stable it is tagged 1.0.
When freezing for 1.1, trunk should be merged into the 1.x makaanga. Once this is tested and stable it is tagged 1.1.
If we have a release 1.3 and a release 2.1 that are both affected by the same security exploit, the following steps should occur. The release branches 1.x and 2.x will be the same as the 1.3 and 2.1 tagged releases. The exploit should be fixed in the 1.x and 2.x branches (or merge a fix from trunk if that can be done). When the release branches are tested and stable, tags 1.3.1 and 2.1.1 should be created from the release branches.
