What do version numbers mean?

Drupal release versions

In Drupal 4.7.x and previous, the first two numbers indicated the Drupal version number, while the last indicated a "point" or bug-fix release with a specific "patch level". For example, "4.7.3" means "the third bug-fix release (patch level 3) of the 4.7 version of Drupal."

This was frequently confusing for people who expected 4.7.x to be a minor update of 4.6.x, when in fact this was far from the case. Different versions of Drupal often break API compatibility with one another, and require contributed modules to be upgraded.

Starting with Drupal 5.x, the "5" indicates the major version of Drupal, and the .x is the bug-fix release or patch level. That means that 5.0, 5.1, and 5.2 all have the same underlying structure and modules for 5.x are all compatible with each other. However, modules written for Drupal 6.x will not work with 5.x and vice-versa.

Development snapshots

A release with "-dev" at the end of the version indicates a development snapshot from the end of a CVS branch (as opposed to an official release from a CVS tag). These snapshots, by their nature, include changing code. It is therefore hard to know exactly what revisions of each file they contain, even if it is a snapshot of a stable branch where only bug fixes and security enhancements are being made (such as the 6.x-dev snapshot release of Drupal core). This makes them more difficult to debug, and they should generally be avoided for production sites. Development snapshots also use "x" for the patch level to further indicate the variable nature of the code they contain. Both Drupal core and the contributions can have development snapshots.

What do contributed modules' and themes' version numbers mean?

As of 2006-11-11 and later

The version number indicates the version of Drupal core the contribution is compatible with, whether it is a stable or development release, and what specific "patch level" of the code it represents. These numbers have the form:

CoreCompatibility-Major.PatchLevel[-Extra]

• CoreCompatibility is required, and will be something like "4.7.x", or "5.x", to indicate what version of Drupal core this contribution is compatible with. Since the API for Drupal core does not change among stable releases, a module that is compatible with Drupal core 4.7.1 would also work with 4.7.3. This is why the version strings for contributions contain the character 'x' to show that they are compatible with any core release ("4.7.x") not just a specific version of core ("4.7.1").
• Major is the major revision number, which indicates what set of functionality a given release has, if it is stable (bug-fixes only) or development (new features), and so on. The default branch for a given release of core (for example, the "DRUPAL-4-7" branch) will be major version 1. By convention, this major revision should always remain stable, and only security patches and bug fixes should be added to it. Optionally, project maintainers could create additional branches, which would have higher major versions (2, 3, etc.). These additional major revisions will be for whatever the maintainer of the project sees fit. It is up to the project maintainer to document on their project node and in their releases how they're using their own branches and what users of their modules should expect from any available major revision numbers. By convention, if the maintainer is adding new features to a module, they would use major revision 2 or higher.
• PatchLevel is for a specific release of a given major revision. The first release would be patch level 0. As bugs are fixed, each new releases would have a higher patch level number. If the patch level is the letter "x", it indicates a development snapshot (see [-Extra] immediately below for more information).
• [-Extra] is optional, and is for specifying things like "-dev", to indicate a development snapshot from the end of a CVS branch (as opposed to an official release from a CVS tag). These snapshots, by their nature, include changing code. It is therefore hard to know exactly what revisions of each file they contain, and this makes them more difficult to debug. Development snapshots also use "x" for the patch level to further indicate the variable nature of the code they contain.

Versions with extra tend to be less stable (development snapshots in particular are inherently unstable) so they should be avoided for production sites. Official releases uniquely identify an exact set of revisions of each file in a contribution. This identifier can be used in many places: the issue queue, the CVS repository, in forum posts, emails, and so on.

Some example version strings and what they mean should help clarify:

• 4.7.x-1.0 The initial (patch-level 0) stable release (major revision 1) of a module compatible with any version of Drupal core 4.7.*.
• 4.7.x-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.*.
• 5.x-1.0-dev A nightly development snapshot ("-dev") of a stable release (major revision 1) of a module compatible with any version of Drupal core 5.*.

Contributed module versions prior to 2006-11-11

If you happen to have an older "release" of a contributed module, the version numbers are different. Prior to 2006-11-11, the version numbers for contributions were of the form "X.Y.0".

• X.Y indicates the version of Drupal that a given module is compatible with. (A module with a version of 4.6 is compatible with Drupal core 4.6.1 and 4.6.2)
• There was no patch level indicator for modules, so the version was always "X.Y.0". Modules were packaged automatically (readied for download in a tar.gz format) from the CVS repository whenever their maintainer updated them. The only way to know what specific code you had and if a newer "release" was available was to check the release date on the projects page to see if it had been updated.

Due to code changes in major Drupal core versions, modules are not expected to work with newer Drupal versions. If you wish to test, please do so on a test system. Otherwise, feel free to help the maintainer by submitting patches to update the module. If a maintainer is unavailable, you can apply to become the maintainer. (See the developers guide for more information).