We've seen explosive growth in 2005 and 2006 based the ability for Drupal sites to rapidly deploy new features that meet real world customer needs, not just fulfill technical requirements. This project aims to increase consultant and site administrators ability to effectively manage releases, security, versioning, issue tracking, and feature deployment into customer ready production environments. By directly improving the Drupal.org release and project management infrastructure we will speed up the life cycle for meeting customer and user requirements and ultimately improve the ability to manage Drupal web sites. Donating to this effort provides funding to accelerate volunteer contributions the Drupal.org project maintainers have made over the past 8 months.

Overview

• Contributions will have real releases and version strings, just like Drupal core itself
• Security announcements will refer to exact versions of modules that are effected
• Issues will be tracked by the exact version number of the contribution where the bug is present
• Development branches for any given version of the Drupal core -- maintainers can add new features to their module or theme without endangering the stability of other code that is compatible with the same version of Drupal core.
• All contributions will be clearly identified with the version of Drupal core they are compatible with
• Users will be able to subscribe via email or RSS to all releases of any project on drupal.org (including Drupal core)

Current total: $1,808.61 (27.8% of total needed)
(Last updated: 2006-09-30)Digg this proposal
Full proposal

Currently, Drupal's contributions (modules, themes, etc) do not have real version numbers or releases. Each contribution is checked-out from the Drupal CVS repository every night, and if any changes were made in the past day, a new downloadable package is created. The link on the downloads page includes a date and timestamp as the only means to identify a specific "release". Furthermore, once a contribution is branched for a given version of the Drupal core API (for example, the "DRUPAL-4-7" branch of the source code is specific to the 4.7.x releases of Drupal core), the package maintainer must choose if they will keepn this branch of the source stable and only fix bugs, or if they are going to add new features (rendering it less stable, but potentially more useful). Problem reports can only indicate approximately which "version" of a contribution has a bug, since there is no consistent way to identify a release (other than by date, and not all problem reports include this information), which makes it harder for end-users of these contributions to report problems and for the project maintainers to find and fix them. If security holes are discovered, the security advisory must refer to file-specific revision identifiers and dates, which are much more difficult for site administrators to know if their site is vulnerable and needs updating or not. This system also makes it basically impossible to define meaningful dependencies among contributed modules. Providing easy ways to specify and enforce these dependencies and integrating them with the new installer profiles is becoming more and more important, especially for modules that define an API that other modules rely on (for example, the Views API, VotingAPI, etc).

What we need is a whole new system for contributed projects to be released, including real version numbers, separate stable and development branches for every version of Drupal core's API, and new functionality to take advantage of these fundamental changes. We propose a minimum set of changes required for the basic infrastructure to enable real releases of Drupal contributions, and some additional functionality that can be built on top of this foundation.

To accomplish all of this will require a lot of work, but will massively improve how site administrators and Drupal developers identify, manage, and deploy Drupal contributions. It will improve the security of sites relying on these contributions, and will allow developers to maintain both a stable (only bug fixes) and a development (new features and enhancements) version of their contribution for every version of Drupal Core that they want to support.

A lot of time and energy has already gone into this work, to design all the parts, get approval from the core Drupal developers (in particular, Dries and Gerhard (killes)) for the approach, and so on. For more of the gory technical details, you can read http://drupal.org/node/58066. What is now needed is funding to pay for the actual code.

Fundraising

The fundamental infrastructure will require $3500 worth of development:

• port project.module to use real nodes for releases (see http://drupal.org/node/75053)
• add new functionality to cvs.module to interact with project_release nodes
• changes to external packaging script to properly build release packages, update release nodes with appropriate info, publish them, etc.
• minimal support on project nodes for displaying more downloadable releases: (UI for selecting "active" branches to display downloads for, 2 tables for real releases and nightly development snapshot packages).

Additionally, once the above foundation is in place, the following new functionality would be possible:

1. People could subscribe via email for all new releases for a given project. ($400)
2. drupal.org could provide an RSS feeds for all new releases for a given project. ($400)
3. drupal.org could provide an XMLRPC interface for getting current versions of all projects available for download. the drupal administrator's modules page would be modified to use this XMLRPC interfaceto indicate modules installed on your site that need upgrades. ($1000)
4. drupal.org could provide a new view of the contributions download pages in a "project compatibility grid". see http://drupal.org/node/63491 for more details on this. ($1000)
5. drupal.org could provide a "Recent releases" block, where site visitors could always see the latest releases of various contributions. This would help users notice new releases, and also get a sense of which contributions are being actively developed and improved. ($200)

The total required for the entire proposal is $6500, which is obviously a lot for any individual sponsor. Since these changes will benefit the entire Drupal community, we are looking for any contributions, no matter how large or small. To contribute, you can use the PayPal donation button, or at least help raise awareness about this effort by Digg'ing this article with the link below:

Current total: $1,808.61 (27.8% of total needed)
(Last updated: 2006-09-30)Digg this proposal

Thank you for your support for this important work!

-Derek Wright
(maintainer of the Project, Project issue tracking, and CVS managment/tracker modules).