Thoughts for module maintainers regarding the Drupal upgrade cycle | Pixel Clever

Drupal hit it big when version 5 came out. Before this time it had a considerable user base, but it hadn’t gone main stream yet. The transition from Drupal 4 to Drupal 5 was extremely quick. No one held on to Drupal 4 and all significant modules released 5x versions within a few months. When Drupal 6 came out last year I think many of us expected the same kind of quick upgrading and transitioning, but alas, and many important modules have taken their sweet time coming out with a 6x release. I’m not going to point the spotlight at any modules or their maintainers, but there are certain modules that still don’t have a stable release as of this writing. I think we can all agree that this is not ideal. As a community we rely on the contributed modules, many of us have livelihoods that depend on them in fact. No one has time write every module needed by themselves so it should be clear that it is in everyone’s best interest that we improve the speed and efficiency of the Drupal upgrade cycle.

So what parts of the Drupal Development cycle need to be altered?

The way I see it there are a set of priorities that should be codified in a similar way as the Drupal coding conventions have been. That is to say we need a set of general rules that guide the upgrading of modules. I’ve spent some time thinking about this idea and I have come up with the following principles:

1. The first priority should be to release a stable version of the module for the new Drupal version based on the last stable code. This means don’t try to add lots of new bells and whistles to your module for the first release. There will be time for that later. Get a simple version out that only makes alterations as are needed to match the api changes in the new version of Drupal.

2. Bug fixes should come before features. Just make it work correctly, clean up the code, get rid of obscure php errors, browser incompatibilities, etc… I think we can all name at least one module that is guilty of adding tons of new features while leaving scores of unresolved bug reports on their queue.

3. Don’t wait until other modules are finished to create the first upgrade release. At least put out a dev release that adapts to Drupal api changes. Waiting causes a chain reaction that clogs the flow of development.

Anyway, those are my thoughts on the issue. I really think there needs to be more discussion about this at the upper levels of the community.