Notes for "Talk on maintaining your Drupal modules"
Last modified: December 4, 2007 - 22:08
Here are notes summarizing Derek's talk "Maintaining your Drupal modules". They are a rough sketch and are no substitute for listening to the talk or reading Releases and update_status.
Talk on maintaining your Drupal modules
=======================================
[1:28] Nobody's obligated to do this
[2:24] Once you upload it, you expect that other people are going to use it. Thus responsibilities:
1. Security vulnerabilities
2. Clear statement of intentions
1. Forum post
2. Sandbox
3. CVS project without official release
4. Official releases
For those of you who can't be bothered to maintain: if it's specific, don't release it; if it could be useful, post it, but say you won't be able to maintain it.
3. Keep userbase in mind (more popular modules have more problems)
4. Bad modules give Drupal a bad name
[13:52] Goals as a maintainer
1. Release things right, and less support requests arise
2. Make it easy to keep moving forward (new features)
3. Make it possible for people to use your module
4. Handle security issues quickly
[18:04] Three main areas of tools
1. Revision control system (CVS specifically): Branches and Tags
2. Releases
1. Development snapshots
2. Official releases (immutable)
3. Drupal.org project nodes
[19:20] Branches and Tags
1. Branch forks development progress
2. Tag gives a name to a specific set of files at certain revisions, cannot be changed
(Explanation of branches and tagging workflow)
[27:09] Releases
1. Official release = tag, makes things easy
2. Development snapshot = most recent work on branch/HEAD, must be dated
- Never tell regular users to use snaps
- Useful for helper developers who don't want to use CVS
- Branches useful for maintaining module code for multiple Drupal APIs. Older branches can be maintenance only.
- Keeps stable things stable while you do crazy development stuff.
- Release notes explain what each branch is, and changes in the release (are out of the way, so often this is reiterated in the text below the teaser) (different from CVS logs in that it is more condensed)
- Some talk about unit testing (Simpletest, Selenium)
[47:17] How and when to make a release
- Make a release when you think it's worth it for the users to upgrade
- When a new release is posted, admins *will* get notified about it
- Don't make an official release after every change
- Security fix get an immediate release
- Critical bugs should get a new release, use your judgment, many use a beta
[51:33] "update_status is smarter than you think"
- update_status is a module you install that tells you about what other modules need to be updated
- It knows what you have and what's available, and calculates whether or not you need to upgrade
- When you add a beta, it is added as "also available", but doesn't tell the person to upgrade; only when there's no "extra" column
- If you add a security release, update_status goes nutso with big red letters "YOUR SITE IS INSECURE" (this is one of the specific purposes of update_status)
Case study "update_status":
- 1.x version was fundamentally flawed
- Once 2.x-rc1 was released, it was recommended, since it was much better
- "OH, YOU MUST NEVER, RECOMMEND, A NON-OFFICIAL VERSION URR!" -- Derek in a histrionic voice
- If you need to fix a release, make a NEW release (1.4, not 1.3-2; update_status can't understand it)
- Version with "extra" is not good
Case study "eCommerce":
- Alpha version is recommended version
- Admin has option to pick recommended branch
- update_status will then prefer that branch over all the others
- eCommerce set 4.0 as recommended, even though the only release was 4.0alpha
- Then everyone complained
- Issue queues more looked at than forums
Digression: If you have CVS access to a project, you can do everything except give other people access
Future features: New vocablary, "paid-for", etc.
- CVS: node/59, send a description, once a week the CVS admin reviews the apps and accepts/denies
- Securities issues are good! They mean that the module has been reviewed
- CVS/SVN: Would require too much retraining/tool changing, for just one new feature (not enought better). Would require something more drastic like git, and not even
[1:20:40] Using CVS HEAD branch
1. Cutting-edge development on HEAD, always release from there, lots of work but most productive
2. Every new branch needs a branch, which then gets tags
Note that Core doesn't worry about this stuff (branch never adds new features (feature-freeze), all goes in HEAD).
- Branch lets you release a security fix without having to add all the other gunk (new features)
As long as you communicate your intentions, most things should be fine.