Drupalmodules always have at least two categories of releases: the stable, "recommended" release and the "development" release. But a few modules have a third category called "other releases". Should you ever use the "other" release on your site? It depends.

These "other" releases are like a recommended release, in that the maintainer releases them deliberately. They are probably more stable than the "dev" releases.


Actually, sometimes they're quite stable, and might even be a smarter choice than the recommended release. Other times, they're not really recommended for production sites. You need to read the module page carefully to find out.

Not Quite Stable Yet

For instance, let's say Drupal 8 is approaching. You might see a Drupal 8 version of this module, 8.x-1.0, as an "other" release. This lets you know that the maintainer thinks that this version is somewhat more stable than the "dev" 8.x version, but it's not necessarily stable enough for production sites. If you use drush on a Drupal 8 site, you'll get a warning that there's no recommended release, and you'll have to choose this manually.

Of course, some developers are more paranoid than others. You can find modules that are in use on tens of thousands of sites, but are still officially "beta".

Multiple "Major Versions" Of a Module

Another use for an "other" release is a stable-ish version of the next "major version" of a module. You see this when a maintainer is developing a new major version of the module, but needs to maintain the older version too.

(Note: both these "major versions" of the module will be designed for the same "major version" of core. It's really confusing that the phrase "major version" is used in a similar but separate way for core and modules.)

The new major version for the module probably has new features, but the old major version is probably more stable and already installed on many sites.

Let's say the "recommended" release for a module is 7.x-1.4 and the "other release" is 7.x-2.0-alpha3. In this case, the maintainer wants to publish the new "2.0" (literally) features, but the label of alpha3 and the choice to make this an "other" release both emphasize that you will use these new features at your own peril. If your priority is stability, you should stick with the older 1.4.

Upgrades are another issue. There might not yet (or ever) be a simple upgrade path between 1.4 and 2.0-alpha3. So the maintainer can't make 2.0-alpha3 the "recommended release", because all the developers running 1.4 would get an automated notice to upgrade. If they tried to upgrade, they would break their sites.

Meanwhile, the maintainer might discover a critical bug in 1.4. This will mean releasing a new recommended release, 1.5, with a fix, while still keeping the 2.0 branch separate.

Eventually, the 1.x branch will be abandoned, and the 2.0 branch will take its place as the recommended release (simple upgrade path or no). But that can take years.

On the other hand, the "other" release can sometimes be the wiser choice. The "other" release may be just as stable as the older, "recommended" release, but the older version is still "recommended" only because there's no clean upgrade path. In these cases, you're actually better off starting with the newer "other" release, because you won't get stuck with the old version that can't be upgraded.

When you see an "other" release, read carefully to figure out which version to use.