I don't think this information is as well publicised as it should be. It should be upfront of module downloads.

It's quite possible for a regular user of Drupal to download modules without having a clue what the version number/name means.

Extra Tags

  • DEV: follows the working progress of the module. It's the latest and greatest version of a module. It also may not work. Say the coders had removed a file but not yet replaced it. It's your risk.

  • ALPHA: is a release between colleagues, for assessment. Sometimes teams put out perfectly good ALPHAs. However, if it blows up your washing machine, well, it's labeled ALPHA for a reason - it might be hazardous.

  • BETA: either internally tested, or gen rally understood not to not to wreck havoc. Not expected to work very well though, that's what this stage is for.

  • RC: Release Candidate. We think it's ok, no more critical bugs. Feature freeze, i.e. No more new features.

All of the above are not stable for production use, i.e don't use on a working site.

Examples,

I once downloaded a ALPHA version of a module. IT slewed my database, crashed my site and uninstalling it did not fix the damage. Shame I couldn't see what it did, but that's ok - it was an ALPHA.

Treemenu modules have generally been released as BETA i.e not expected to cause damage, but untested. One of the BETA's lacked a file, so could crash installations. That was a fault with my release, not the labeling. Had it been properly uploaded, it should have been BETA.

Version numbers, working along the line,

  • 6.x most people get this - it's for version 6 of Drupal

  • 6.x-2 This number is for versions. A version is expected to be stable and add only bug fixes. A new version includes new features, so if new features are added to this, it becomes 6.x-3.

    You can not update between versions just as you like. You are expected to properly uninstall the module then reinstall the new version. However, with Drupal modules you often can rip the old version out and put in a new one. It is a risk, though.

  • 6.x-3.0 This last number is for bug fixes. So if we fixed a bug in a module labeled like this, it would become 6.x-3.1. You can safely, and are recommended to, use these updates.

Finally

  • Recommended - if you start from scratch, this is your recommended release.

  • Supported/unsupported - are we still working on this one, or do we expect you to upgrade?

(on tags/version numbers)

Comments

jptaranto’s picture

jptaranto CreditAttribution: jptaranto commented

I guess I have always seen the 2.0 to mean version 2 added more features or was otherwise quite a lot different to version 1.

So if there were one or two bug fixes or extra features in version 1 it would become 1.1 or 1.2 rather than 2.0

At the beta stage I would have also though that 6.x-1.0-beta1 would become 6.x-1.0-beta2 after a substantial amount of testing had gone on and bugs had been fixed, but it wasn't quite ready to be an rc just yet. Should some features be added it would also increase in beta number?

I guess it's all kind of confusing and really depends on the philosophy of the creator(s)?

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

Ha!

I'm following Drupal recommendations to the letter. The core release schedule clearly follows this pattern.

But it is overload for a module. Taking Treemenu as an example, we'd be releasing a new version on every release, as features and major areas are developing rapidly. JP's intuitive approach - point releases for undisruptive new features, makes more sense.

So that's the policy from now on. Point releases for bugfixes AND undisruptive, backward supporting features.

As it happens, this scheme still fits what has been done so far.