Overview of contributions branches and tags

To understand the naming conventions for the branches and tags used for Drupal contributions, you should already be familiar with the version numbers for contributions.

There are three types of CVS identifiers now used in the contributions repository:

• Official release tags
• Stable branches
• Development and other branches

Official release tags

All releases of contributions are created based on release tags. These tags determine the specific revisions of each file included in the release. The tag name itself corresponds with the version string for the release. The release tag naming convention is:
[CoreCompatibility]--[Major]-[PatchLevel]<-Extra>

• [CoreCompatibility] indicates what release series of core (e.g. 4.7.x, 5.x, or 6.x) the release is compatible with. It uses the same form as the Drupal core branch for that core release series. For example: DRUPAL-4-7 or DRUPAL-5 (any value from the complete list of available Drupal core branches).
• [Major] is an integer that indicates what major revision of the contribution the release is from. Most of the time, this will be 1 to indicate the initial stable release for a given version of core, but occasionally contribution maintainers might provide multiple versions that are all compatibile with the same version of core (e.g. stable and development versions). A maintainer might choose to use major revision 0 to identify releases from the HEAD development branch that are being ported to a new version of the core API, but which aren't yet stable enough to have their own branch.
• [PatchLevel] is an integer that uniquely defines the specific release. The initial release for a given major number is patch level 0 and subsequent releases increase the patch level.
• <-Extra> (optional) can be used (in rare cases) to specify additional identification for a release. For example: -BETA1 to indicate the first beta release. These extra tags may not include spaces, hyphens, or underscores.

Some examples of tag names and the corresponding versions they represent should help clarify:

DRUPAL-4-7--1-0

The initial (patch-level 0) stable release (major revision 1) of a module compatible with any version of Drupal core 4.7.*. This would be version 4.7.x-1.0.

DRUPAL-4-7--2-1

An updated (patch-level 1) new-feature release (major revision 2) of a module compatible with any version of Drupal core 4.7.*. this would be version 4.7.x-2.1.

DRUPAL-5--0-1

An updated (patch-level 1) unstable release (major revision 0) of a module that's not done being ported to the 5.x core API. This would be version 5.x-0.1.

DRUPAL-5--1-0

The initial (patch-level 0) stable release (major revision 1) of a module compatible with any version of Drupal core 5.*. This would be version 5.x-1.0.

DRUPAL-6--2-0-BETA1

The initial (patch-level 0) beta 1 release (major revision 2) of a module compatible with any version of Drupal core 6.*. This would be version 6.x-2.0-beta1.

Historically, the 'extra' element at the end of version tags allowed lowercase letters, hyphens, and underscore characters. As of 2007-07-31, this is no longer supported: the optional 'extra' element at the end of a version tag may only consist of capital letters and numbers. See issue #147494 for background on this change.

Stable branches

Once a contribution has been ported to a given version of the Drupal core API, the maintainer should create a branch that marks it as compatible with that version. This is not technically required, but is definitely recommended for responsible project maintainers. These initial stable branches are similar to the branch names used by Drupal core branches, with the addition of the module's [Major] version number. For example, the initial release of a module compatible with Drupal 6 should be branched with: DRUPAL-6--1.

The releases corresponding to branches, even "stable" branches, use -dev at the end of their version string to indicate that the code contained within that release is constantly changing and inherently unstable. So, the release pointing to the DRUPAL-6--1 branch would have the version 6.x-1.x-dev.

Historically, the Drupal Contributions repository supported 'partial' branch names like DRUPAL--4-7 and DRUPAL-5, treating them as synonyms for DRUPAL-4-7--1 and DRUPAL-5--1. Starting with the DRUPAL-6 core branch, code in the contributions repository must use fully-named branches, like DRUPAL-6--1 and DRUPAL-6--2.

Development and other branches

If a project maintainer wishes to provide a development branch for a given version of the core API, they would add a branch of the form:
[CoreCompatibility]--[Major]

• [CoreCompatibility] indicates what release series of core the branch is compatible with. This is just like the first part of a release tag (explained above). For example: DRUPAL-4-7 or DRUPAL-5.
• [Major] is an integer that indicates what major revision of the contribution the branch represents. In the case of development and other branches, the major version number must be 2 or higher, since the default stable branch for a given version of core (e.g. DRUPAL-4-7) corresponds with major revision 1, and by convention, releases with the major revision 0 (if used at all) are always from the CVS HEAD.

Again, some examples of these additional branch names should help clarify:

DRUPAL-5--2

The first additional branch of a module compatible with any version of Drupal core 5.* (by convention, for new feature development) This would be where versions 5.x-2.0, 5.x-2.1, etc. where released from, and the development snapshot release would be called 5.x-2.x-dev.

DRUPAL-6--3

The second additional branch of a module compatible with any version of Drupal core 6.*. Perhaps after a period of developing new features in the 6.x-2.* series of a module, the maintainer decided to create a new stable branch and use that as the new default download of their module. This would be where versions 6.x-3.0, 6.x-3.1, etc. where released from, and the development snapshot release would be called 6.x-3.x-dev.