Release Policy
From Habari Project
Habari has a policy to release often, meaning we plan several major 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. Branching should take place at least two weeks before release. A major version introduces a new API, and therefore major versions have incompatible APIs. Significant new functionality will be added in major releases.
Major Point Releases
An example of a major point release is 0.4. The release branch for a major release is a feature frozen branch created from trunk. Branching 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.
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 a blocking (perhaps just "major"?) issue for release.
Point releases do not add additional functionality unless it is added specifically to address the above issues. Except in the case of security issues, a minor point release should not affect the performance of plugins or themes, and should only contain the minimum changes required to resolve the issues. 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 dev 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 to 0.9 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.
