Types of releases for full projects

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 (.tar.gz file) generated will always point to the same group of files; just as downloading Drupal 6.1 will always point to the same files tagged 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.

Development releases

Development releases are automatically rebuilt from the end of a Git 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 releases 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 releases are going to be harder to debug, etc. Therefore using development releases 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 releases 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 stable 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. Any profiles that are getting an update that includes security fixes that are in modules/themes packaged with the profile can likewise use it to get the benefits of update.module. If a profile ships with code and there is a security issue in its code then it should follow the normal rules for a module.

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.