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?
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.