Types of releases

There are two main types of releases:

• Official releases based on a fixed release tag.
• Development snapshot releases generated from the end of a branch.

Official releases

An official release is created when a project maintainer specifically tags their module for release, thus indicating it as "stable" for a particular version of Drupal. Once files are tagged and an official release is created, the tarball generated will always point to the same group of files; just as downloading Drupal 6.1 will always point to the same files tagged DRUPAL-6-1.

Official releases may be marked either as recommended, supported, or unsupported.

• A recommended release means that the project's maintainer believes that this release is the most appropriate release for a given version of Drupal.
• A supported release means that the project's maintainer feels that this release may not be the most appropriate release in most circumstances. Often, this is because this release is either old or very new. In general, supported releases are stable but users should consider using the recommended release on production sites unless there is a specific reason not to do so.
• An unsupported release means that the project's maintainer feels that this release should not be used. In most cases this is because the release is old and has been replaced by a newer version. Users of unsupported releases should not expect module maintainers to fix bugs present in such releases.

Snapshot releases

Development snapshots are automatically rebuilt from the end of a CVS branch. As a project maintainer, all you have to do is make sure you have the right branch created (see below) and submit a single release node pointing to that branch. After that, there's nothing else you have to do. The packaging scripts will detect if there have been any changes made on that branch, and if so, a new package will be created (which will have a new package date, and md5 checksum, but not a new version number).

Since the code keeps changing, but the version string does not, development snapshots are problematic for everyone involved. Users have a moving target, it's hard to identify the exact code someone is running, issues that reference development snapshots are going to be harder to debug, etc. Therefore using development snapshots is discouraged. The functionality to produce them only exists to give people an easy way to get the latest code if they want to help with testing and debugging. Responsible project maintainers should always provide real releases so that users of their contribution do not have to use development snapshots for production sites.

Release types

When creating or editing a release, you may specify a Release type. The possible values are:

Security update

This release contains a critical security update. Any release associated with this term should have a link to the corresponding security announcement in the release notes. Please see the Contacted by the security team. Now what? handbook page about the proper way to handle security-related releases.

Bug fixes

The release should be marked with this if it contains any non-security related bug fixes.

New features

In general, new features should only be added to development branches for your project, but any release that contains new features should have this term.