Release Cycle

Backdrop aims to deliver features to end-users more quickly with more frequent, "minor" releases every 4 months. At the same time, APIs move slowly over longer, "major" release cycles that happen every 3 years. Backdrop encourages both developers and end-users to upgrade through the features it delivers. In our Roadmap page, you can see a summary of the changes and features added to past releases as well as what we are planning for future releases. For a more detailed changelog of all releases, see the release history on Github.

Version Numbers

Backdrop uses semantic versioning (which is also used by Drupal 8). Take a closer look at version 1.2.4, for example:

1.2.4

Major

Incompatible API changes
(3 years)

Minor

Backwards-compatible feature and API additions
(4 months)

Patch

Backwards-compatible bug fixes
(as-needed)

The whole thing is based on the http://semver.org model. In "plain English", user experience or developer experience improvements (tagged as [UX] and [DX] respectively on GitHub) with no functionality change, i.e. changing a string of help text on a field (may require updating of existing tests) can go into any bug fix release, minor release or major release. So an increment from 1.5.1 to 1.5.2 for example could fit this example.

Improvements that require a change in functionality (and therefore new tests for that functionality) need to wait for a minor release. This would be an increment for example of the middle number like from any 1.5.x release to 1.6.0.

Improvements that change/break an API that downstream developers are relying on in contrib or custom modules in Backdrop sites require a major release from 1.x.y to 2.0.0.

Branch Management

The amount of work can be kept to a minimum by organizing development branches cleverly with Git. Bugs will be fixed in the patch release version first, which is merged into the minor release, which in turn is merged into the major release. This means when fixing bugs, the fix is made to the production version of the software first, and then merged in to the future version.

Release cycle branch management diagram.
"Current version first" branch management, where features and bug fixes are added to the current ("Primary") version while continuously being merged into the future version. Note that to save space, the "patch" versions for the 2.x branch are not shown.

Timeline

  • Patch or bug-fix releases will be made as-needed.
  • Minor releases providing new features, API additions, and polish will be made every 4 months. A minor version will be released on the 15th of January, May, and September.

    Feature Freeze Two weeks before each minor release, any issues tagged "feature request" in the release milestone that have not yet been committed will be bumped to the next release milestone. After that point we want to focus on the features that have been committed; get them polished, well-tested, and fix any bugs that are discovered before release.

  • Major releases are currently intended to be made about every 3 years, but this length of time has not yet been officially established as policy.

API Compatibility

Backdrop aims to provide API-compatibility even as new features are added within a major version. However, due to the number of publicly available APIs with Backdrop, absolute compatibility is not realistic. In this case, API compatibility within a major version means no modifications to the following:

  • The signatures of public functions (those not starting with underscores).
  • The signatures of protected and public methods on classes and interfaces.
  • All hooks and their signatures.
  • The HTML markup of front-facing (non-admin) callbacks and templates, and the contents of their variables.
  • Form API element properties as specified by their corresponding hook_element_info() implementation.

However the following things may be changed, even in a minor release:

  • The signatures of private functions (those starting with underscores)
  • The signatures of private methods on classes.
  • The complete detail of $form (or other renderable) arrays, as exposed to hook_form_alter() implementations.
  • Database and configuration schemas.
  • Settings available in settings.php.
Portions of this page modified from Semantic versioning for Drupal 8.x proposal.