Official releases
An official release is created when a maintainer specifically tags their project for release, thus indicating it as "stable" for a particular version of Backdrop. Once files are tagged and an official release is created, the .zip file generated will always point to the same group of files. Downloading the .zip for Backdrop 1.24.0 will always point to the same files tagged as 1.24.0.
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 Backdrop.
- 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 very old or very new. In general, supported releases are stable but people 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. People using unsupported releases should not expect maintainers to fix bugs present in these releases.
Release types
When creating a release, maintainers can indicate a Release type using semantic versioning for the tag name.
- Bug fixes
If the release contains any non-security related bug fixes, the final number in the tag should be incremented.
A new bug fix release for a project tagged with 1.x-1.0.0 would be tagged 1.x-1.0.1. - New features
If the release contains new features, the second number in the tag should be incremented.
A new feature release for a project tagged with 1.x-1.0.0 would be tagged 1.x-1.1.0.
Security releases
A security release contains a critical security update. This kind of release is almost always a bug fix release, but in rare occasions the fix for the security issue may be the addition of a new feature.
Every security release should have a link to the corresponding security announcement in the release notes. Please see the Security Releases page about the proper way to handle security-related releases.
Development releases
In Backdrop, there are no automated development releases.
If a maintainer wants to create a development release, they can tag a project using a tag that ends in in -dev, -alpha, or -beta to indicate to people using these releases that they are still in development.
People may also choose to run the bleeding edge code for a project directly from GitHub, by cloning the git repository, or downloading a .zip of the end of a Git branch. Since the code keeps changing and there is no version information, debugging for bleeding edge code can be problematic for everyone involved. It's hard to identify the exact code someone is running. Therefore, using bleeding edge code is discouraged.