Dev or No Dev?

The other day, Bob Christenson posted a question on Twitter about development versions of modules.

Anyone know of a way to track new official #drupal releases(not hackish, unusable dev versions). The problem is, not all dev versions are bad

Since the question affects a lot of topics we've been discussing in the Churches Group, including conversations about building install profiles, I've decided to write about it here.

Version Numbering

An issue here is that version numbers are not approached quite the same way in modules as they are in core. Since Drupal 5, core's major version number represents a feature freeze. Once cast, a core version's features will not change. Subsequent point releases only contain security and major bugfixes. Point releases usually come as security releases, but some of the other fixes might be committed to dev in between. I wouldn't install a dev release of core into a production site, though I did have to install a core patch into a live site once while waiting for it to appear in the next point release.

Version numbers for modules don't necessarily mean the same thing. The change between a 5.x-1.0 and a 5.x-1.1 release may include bug and security fixes, or it might include the addition of three new features. In general, a module version change (from 5.x-1.x to 5.x-2.x) represents a massive refactoring of the code, sweeping feature changes, or both. Module version numbers can also jump around between versions of core. During the D5 to D6 migration, some modules are being rewritten porting to D6, so we're seeing releases jump from 5.x-1.x to 5.x-2.x to 6.x-2.x in many cases. Other maintainers are resetting their numbers between core versions, so 5.x-4.3 and 6.x-1.0 releases may have the same feature set for a given module.

In between all of this, we have the dev versions. Many modules only have a 5.x-1.x-dev release. For other modules, a dev release may contain critical bug fixes since the last point release, new and highly unstable features since the last release, or both. All of this is at the whim of the individual module maintainers, whose philosophies and motivations may all differ. Some of the bigger modules, like cck, views and panels, are now adopting a more structured approach, with beta and release candidate releases that follow core practices more closely, but there are thousands of little modules out there who don't.

With all of this version soup, what is a site builder to do?

Following the Changes

The following process has worked pretty well for me, though it's not foolproof. Bob's tweet really has two aspects: which dev modules to use, and which versions of any module to install. The former question ties into Future-proofing your Drupal install, and the latter might keep you from completely trashing your site. (Of course, we all back up first, right?)

For new (to me) modules, I probably look first for a 6.x version, even though I'm working in D5. A stable 6.x release probably means the maintainer is looking forward. Some developers are now writing modules for D6 and then back-porting to D5 because it's easier to write clean modules this way. I also look at how the project description is worded for clues about how the developer thinks. I generally trust modules that are maintained by well-known Drupalers, but got caught this week over module interaction issues, so that criteria is not infallible. If I don't recognize the maintainer, I may go to their user page and see what other modules they're associated with, and look at their track page. I look at the dates between release and dev versions, and whether either is recent.

After that, I look at the open issues. If the first page is full of issues that indicate the module doesn't even work, I'm usually done. I also look for open issues stating problems interacting with other modules that I use. If the newest issue is several weeks old, they'd all better be pretty trivial.

Finally comes the decision of whether or not to use the release or dev module. Under the Development section on every project page is a link to "View CVS Messages." I go in there and read what changes have been committed to the dev release since the last stable release date. If these are seemingly trivial changes or new features that I won't need, I'll install the release version.

I take this same approach for updates. If I've installed a release version, I won't update to a development version unless something is broken. I'll update releases pretty quickly for security issues, but probably slower for fixes that don't affect my site. I keep a spreadsheet of the modules I use on my sites which includes the dates for all dev versions I use. That helps me compare CVS commits between dev releases.

Install Profiles

I said I'd bring this back to install profiles. I use a lot of modules that simply don't work without critical bug fixes that exist in their dev releases, but the maintainer hasn't rolled a new stable release from these changes. In the meantime, they may or may not have rolled new commits into that dev release since the patches that are needed. I don't see a lot of success if we try to build install profiles that rely on dev releases that might change underneath us without notice. I think that's why I'm in favor of site recipes instead of packaged solutions.

Hopefully, a lot of this will get resolved as Acquia builds their Carbon distribution of Drupal 6. Since Carbon will contain contributed modules along with core in a commercially supported distribution, they're obviously going to have to have stable versions and more structured maintenance of the included modules.

Anyone attempting to build an install profile for churches will need to establish some sort of relationship with maintainers of other modules they're using. It may be as simple as opening an issue saying something like this: "I've been using the dev version of this module with the latest patches in a stable production environment for x weeks. This version works, please roll a release package that includes these updates, so I can use it in an install profile." This request could have more strength behind it if there is a group of testers involved, and writing some SimpleTest routines probably wouldn't hurt, either. The maintainer might even be edified by the fact that their module is being used in this way.

As Drupal matures, I'm sure that module maintenance procedures will have to mature with it, but that's no guarantee that it will ever be perfect. Though I'm not a complete fan of install profiles, I agree that most sites need a common starting point. If we can work together to find a group of modules that will handle 90% of the heavy lifting for most church sites, then we can probably work together with the module maintainers to keep those modules running smoothly. Then we'll have a common direction and a set of modules that we can trust as a starting point for most of our projects.