Drupal Core Branch Labels in DrupalCI

Last updated on
15 December 2021

This documentation needs work. See "Help improve this page" in the sidebar.

When configuring DrupalCI for testing, project maintainers have multiple options available when choosing which version of Drupal Core should be used for running their project's tests.  Since Drupal Core is a moving target, and new branches appear twice a year, we are using semantic branch labels to allow project maintainers to express what type of core environment they want without being forced to maintain the exact versions or keep up with Drupal core’s release cycle

Branch Label Descriptions

The following five labels are available to choose from:

  • Stable
  • Security
  • Supported
  • Pre-release
  • Development

Stable

This option will run tests with the most recent stable release of Drupal. This option allows project maintainers to develop and work against a known, stable, unchanging version of Drupal Core, shielding them from potential upstream changes that might leave them wondering if tests are failing because their changes introduce bugs, or if something changed in Drupal Core to break their modules.  

Security

The security option will run tests against the most recent release that is still receiving security support. This is generally the slowest moving label with the least amount of changes.

Supported

The supported option will run tests against the most recent bug-fix/patches that have changed in Drupal, but have not yet had a release. The branch will not receive major development or api additions, and is not likely to have major changes happening to it during its lifecycle. It is possible that a project relies on undocumented behavior that gets altered by a bug-fix or a security improvement, and this option allows maintainers to know if there is a problem before the point release is tagged.

Pre-release

During the release cycle, there is a two month window where there is a 5th option. This is where all of the minor alpha/beta/release candidate changes are taking place, polishing up the release, while simultaneously allowing major development to continue on the main Development branch. The 'supported' branch is still available as there may still be security or bug-fixes that happen during this window. The most likely use case for selecting 'pre-release' is if you are working on a module that depends on new features in the next minor release and want a more stable environment to test against than the main development branch, to work out any remaining issues in your module.

Development

Development represents the latest development branch of Drupal Core. Project maintainers who wish to run tests to make sure that their projects are not relying on accidentally removed APIs or undocumented features that change behavior should select this to demonstrate that their project still passes all of its tests with the latest changes. This is also a useful choice if there are brand new features/APIs in Drupal that your project wants to take advantage of or relies upon to function, but are not yet released.

Choosing Branches

The right option or combination of options for any particular project is highly dependent on where that project is in it's development lifecycle.  For projects that are under heavy development, it might make more sense to configure testing to use 'Stable' or 'Supported' in order to ensure that project testing is not happening against a moving target, or at least a very slow moving one.  For projects that are stable, and mostly in maintenance mode, it might be a better option to have project tests run against 'Development' so as to be alerted to breaking upstream changes as early as possible.  For projects looking to work with new features and new APIs, the 'Development' and 'Pre-release' labels would probably be where to focus testing so as to ensure that when the next minor release of Drupal is available, your project is already fully tested with it.

Each of these semantic branches are *within* a major version. (e.g. Drupal 8, 9, or 10). No testing configurations will be automatically migrated to the next major version without maintainer intervention.  The assumption is that maintainers will need to do that in order to make their projects compatible with the next version in any case, so automatically moving the label would just create broken tests.

Help improve this page

Page status: Needs work

You can: