Drupal standard naming conventions
Each Drupal project, either a module, theme, or installation profile, gets its own Git repository, hosted at http://git.drupalcode.org. The Git repository for each project, regardless of project type, lives at the URL http://git.drupalcode.org/project/PROJECTNAME.git, where PROJECTNAME is the machine-readable name of the project.
For Drupal core, there is a Git branch for each major version of Drupal. For example, the last few branches of http://git.drupal.org/project/drupal.git are 5.x, 6.x, and 7.x. Modules and themes use branches for each new major version, as well as releases for new versions of Drupal core. Their branch naming convention include the Drupal core version and the module's version number. Example branches include 6.x-1.x, 6.x-2.x, and 7.x-2.x. You are free to name your branches whatever you like for your day-to-day work: awesome-new-feature, experimental-redesign, performance-bugfix are all acceptable branch names. Git's default master branch should not be used and no downloadable releases can be tied to that branch. Master branch cleanup information here. Use 6.x-1.x, 7.x-1.x or 8.x-1.x as your main development branch (see below).
7.x-dev release (core)
7.x-1.x-dev release (contrib)
7.x-2.x-dev release (contrib)
Tags are used for individual releases of a project. For example, there is a new tag for each new minor release of Drupal core, a few of the latest being 6.19, 6.20, 7.0-rc-4, or 7.0. Modules and themes use a tag naming convention including the Drupal core version and the module's version number. Example tags include 6.x-1.0, 6.x-1.1, and 7.x-2.0-alpha. This naming convention is important for our Feature server. Note that release tags must be made on the properly named release branch. Any tags/branches you intend to translate into actual downloadable releases on Drupal.org (as tarballs and zip files) need to follow this convention:
7.0 release (core)
8.0-beta1 release (core)
7.x-2.3 release (contrib)
8.x-2.0-alpha6 release (contrib)
Important note about release tags Only the following labels, lowercase, can be used in release tags:
- alpha - These are the first to come out, and are therefore the least stable. Most reported errors are resolved but there are most likely still outstanding known issues, which might include security issues.
- beta Beta releases are usually only created once:
- All critical data loss and security bugs are resolved
- The APIs are frozen enough so that contributed module and theme authors can start upgrading their projects.
- Most of the problems with the upgrade path are fixed and it's possible to successfully upgrade a copy of the Drupal.org database to the new Drupal version.
- During the period of beta releases, usability features are still considered, the translatable strings (help texts, words in the interface, etc) might be altered, and if absolutely necessary, the API or database schema could change (to fix a critical bug). Of course, other kinds of bug fixes are always applied.
- rc Release candidates are usually only created once no more critical bugs have been reported in a given beta release. These are considered nearly stable code, something the Drupal development community is considering as a candidate to be released as the official .0 version. No more usability changes are made, and the translatable strings are usually unchanged at this point.
Once a feature freeze is announced, no new features will be added to that version of Drupal. That version of Drupal's feature set is locked and any new features or change of behavior will need to go into the next release version.