Recently there was a bit of heated discussion on the development mailing lists (the good kind!) about module developers doing proper releases.

The jist of it being that some modules never get a proper release tagged, and exist as a constantly changing ‘dev’ version that is mostly stable but at any time could contain showstopping bugs as new features are constantly added to the tree.

Sure, you may argue that using a dev or release candidate on your site is bad practice, but often they are very stable (it completely depends on the maintainer) and necessary to use. The problem comes, I find, in upgrading these dev modules. Do you always jump to the latest dev version when you have the opportunity? I find that in the absence of proper releases, or pressing bugs and security issues, sticking to the mantra “if it ain’t broke, don’t fix it” is the best way to handle dev modules.

The important thing when upgrading, is to study the commits, release notes and issue queue to see what has changed. Sure, it takes a bit of time, but it can save you a lot of heartache down the line. Things can break in the strangest ways. For example, the imagefield module going from release candidate 4 to release candidate 6 of version 2. Should be more stable, right?

Well, RC6 has an absolute disaster of a bug that prevents it from working with single image fields.

With proper versioning, generally it’s safe to upgrade from one bugfix version to the next, for example from 1.6 to 1.7 of a module, when new features are being added into a separate branch. Don’t make the mistake of thinking the same thing is true of dev releases.

To check out the issue queue of a module you’re interested in, check for the link on the module page.

https://www.drupal.org/project/issues/search/cck

Select the version you’re interested in, and search. Now scan the list for anything that looks remotely scary… if the version you’re interested in looks like it’s falling apart, stay away.