Versioning and release process for contributed projects

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Harry Slaughter's picture
Posted by Harry Slaughter on June 21, 2006 at 10:46pm

This document is based on the discussion: new method for contributed project releases and versions. It is a work-in-progress summary of various discussions. Project owners will edit this document in place. Others may leave comments which will be deleted after they are incorporated into the document.

Project Title: Versioning and release process for contributed projects
Project Owners: dww, killes, merlinofchaos

Updated: Fri Jun 30 14:41:11 2006

Note: The scope of this effort encompasses anything that lives in the CVS /contributions/* directory and is also released to the public (such as modules and themes).

Problem

Standardizing and, ideally, automating the versioning/release process for contributed projects.

Proposed solution/workflow

  1. Code Completed - Project owner finishes and thoroughly tests his new release.
  2. CVS Tag - Project owner tags his project. Contributed projects will adhere to standard CVS tagging convention for each release. The precise format of this version number is still under debate. The first version of a 4.7 contrib module will likely be one of: modulename-4.7-1.0 or modulename-4.7.x-1.0. Jeff Robbins has suggested making a web interface for this portion of the process. A module author would only have to log in and indicate that his code is ready to be tagged/released.
  3. Release Creation - "Add Release Tool" (ART) - This will be a web page [TBD: built into project module?] that will allow contrib authors to publish tagged releases of their projects. Author will specify the following:
    1. Version - ie, mymodule_4.7.x-1.0
    2. Release notes - In addition to any CHANGELOG or RELEASE files included with the code, authors will be required to provide notes via ART to explain what has changed in the latest release. 
    3. ART may also include a static value (configurable by project owner) which represents the CVS tag from which nightly builds should be generated. 
    4. Security related - boolean value indicating whether the release is critical and/or security related.
    5. Additional dependencies - any new dependencies (TBD: is this necessary?)
    6. Recommended - boolean (TBD: if this is not a recommended bug/security fix, why is it even a release and not just part of the next version?)
  4. Release Approval - After a Project Owner submits his new release via ART, the information is stored in the DB ({project_releases}). Via ART admin interface (TBD), the "ART admin" will be responsible for reviewing potential releases and approving them for final release. (TBD: is this step even needed? IMHO, a project owner is the only one who should be responsible for deciding if a given set of code changes is worthy of a new release. who, exactly, is supposed to review all the requests for point releases from the hundreds of contributed projects on drupal.org? i'm sure killes wouldn't want to do that, and neither would i... -dww)
  5. Release Packaging -  "cron job" (TBD) periodically queries the {project_releases} table for entries that don't have the "tarball-built" bit set
    1. Generate Downloadable Package - Tarball (.tgz) generated. 
    2. Update DB - Updates {project_releases} to set the "tarball made" bit. 
    3. Release Notification - In addition to the module being made available for download, other actions may take place when a release is created. These may include mailing list notifications or updates to 'latest versions' lists. This will be the last component of the process and may be outside the scope of this initial effort. 
  6. Download Pages Update - The various project download pages query {project_releases} table for matching pid (project id) that has the "tarball" bit set, and displays those.
  7. Version Listenings - Current versions for all supported Drupal releases plus development builds are listed on the front page. Additionally, older releases can be listed from a 'view older releases' link. [edited by merlinofchaos]

Add your comments

Please specify the number of the item you're commenting on. Your comment will be deleted after it has been addressed. Keep it simple and brief. To discuss this in detail or become involved, contact one of the project owners.

Comments

why i proposed a "update recommended" bit for releases

Posted by dww on June 28, 2006 at 7:28pm
dww's picture

re: #3 Release Creation, subpoint 6 -- the "recommended" bool...

if this is not a recommended bug/security fix, why is it even a release and not just part of the next version?

here are a few examples:

  • maybe it fixes a bunch of minor bugs that might bother you if you use an obscure feature in the module, but most users won't care
  • maybe it's a release on the development branch (e.g. mymodule-4.7.x-2.1) and only sites that want to try the new features should upgrade
  • ...

i can see all sorts of reasons a maintainer might want to make a new release yet not believe that every user of their module should immediately upgrade. however, in addition to security updates (addressed via subpoint #4), i can see the need to flag releases that fix critical/serious bugs where the project maintainer recommends all users upgrade ASAP.

that's the idea, at least. :)

-derek

thoughts on web interface for tagging project releases

Posted by dww on June 30, 2006 at 10:15pm
dww's picture

on the 1 hand, that might help project maintainers who aren't familiar with CVS to get this step right. however, the downsides are that:

  1. the webserver process would need cvs write access to the repository. :( that's almost enough to kill the proposal as far as i'm concerned. of course, we'd be as careful as we could be with this stuff, and to be perfectly honest, cvs pserver access isn't all that secure in the first place. but, this seems like a fairly dangerous step to take to hold the hands of contrib maintainers who can't read/understand the handbook pages about how to add CVS tags...
  2. we'd lose track of who actually added the tags (at least via cvs and the cvs.module's tracking), so we'd have to record this via another means.
  3. i'm not even 100% convinced a web form would necessarily be any easier to understand/use than a cvs client. it'd be a fairly complicated bit of code to duplicate the effort of a cvs client (at least the tag command), and we'd then have the burden of documenting this form, instead of pointing people to existing docs for existing clients.

overall, i'm definitely opposed. furthermore, this proposal belongs in a separate discussion. if/when enough people care about this to work on it, it can and should be done after everything else is working. there's definitely no need to work on this before everything else is done. :)

thanks,
-derek