Release Policy

From Habari Project

Jump to: navigation, search

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.


Major Releases

Major releases, such as 1.0, will add significant new functionality. A major version may introduce new APIs, and therefore major versions may have incompatible APIs. There is no guarantee that plugins or themes will be compatible between major releases.

The release branch for a major release is a feature frozen branch created from master. The feature freeze should take place at least two weeks before release.

Major Point Releases

An example of a major point release is 0.4. 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.

The release branch for a major point release is a feature frozen branch created from master. The feature freeze should take place at least one week before release.

Minor Point Releases

An example of a minor point release is 0.4.1, which would be a patch on the 0.4 release. Minor point releases correct issues that are critical to the 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.

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 may contain additional low-impact 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, 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

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.

Master, Release Branches, and Tags

The code in master is usually 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, so release testing and bug fixes occur in a release branch named as the version, such as 0.7.2. When freezing for a major or major point release, this branch is created from master. When freezing a minor point release, this branch is created from the previous release tag, for example 0.7.2 would be branched from 0.7.1.

Changes Merged to the Release Branch

The aim of the release branch is to create a stable release. Development continues as normal in master, with specific changes merged or cherry-picked to the release branch. To try to avoid the introduction of new bugs, merges should be conservative. The following process should be used to get consensus about what changes should be merged.

Once a release branch has been created, no new features should be added to the branch, 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.

If there's any doubt about what should be included, discussion should take place on the developer mailing list, 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.


Personal tools