Wow, long lapse in posts there. Sorry folks. On with the show:
Here's the problem. The Drupal security team do a fine job, following up on reports, auditing contributed modules with a point release to check for security weaknesses, working on core. It's all good, except for one thing:
Contrib release process.
Security updates are rarely just security updates! Normally they're a whole bunch of stuff the maintainers were working on, a bunch of other minor bug fixes that have been queued for a few months, maybe some UI changes and anything else that was languishing in the issue queue when the security team came knocking. So what happens? Security hole is patched, patch is applied to -dev, release is rolled pronto and *everything* goes out the door at once, warts and all.
So it's not a 'security update'. It's a module update that happens to fix a security problem. What if you don't want the other stuff? (Sometimes the 'other stuff' will actually even break your site - that's a whole other blog post, but changing mark-up and CSS in the same branch as a seemingly innocuous 'update' breaks people's websites. Don't do it!) What if your site is stable and you only want the security update, not the other stuff?
You have to go and dig out the patches *specifically relating to security* and apply them. This is more than just a royal pain. Even when you do that, Update Status will continue to needle you that your modules are dangerously insecure, even though you know that is not the case. Gah!
I am told some enterprise Drupal users (and by users, I mean big teams in the corporate world) disable Update Status completely and manage their own security patching the hard way, simply because they don't trust contrib 'security updates' and won't just blindly apply them. God knows, I've blindly applied them a few times and been bitten - hard!
So what to do?
In the short term, if you're a module maintainer and the security team come along and point out a flaw, don't fix the flaw in -dev and roll a release. That's the worst thing you could do. A hurried release is a mess waiting to happen and an issue queue full of support requests.
Instead, patch the latest point release, fixing the security team's concerns, and release that. Sure, you'll have to copy over your current -dev code to push it out the door, but that's what VCS is for! Once your security release is out, and it *really is* a security release, you can reinstate your 'work-in-progress' -dev code and carry on.
This way you have a release that truly fixes the security problem, and *only* the security problem, and you can properly plan your next release instead of doing it in a big hurry. And if people don't keep up to date with your point releases, then they're on their own when it comes to applying security releases made against newer point releases, but that is fair enough. Just don't *force* people to have to do a 'security update' that contains a load of stuff they might want to roll out more thoughtfully at a later date.
And in the future?
Hopefully the move to Git will make a lot of this easier. Without going in to detail, Git's superior branching abilities should make it far easier for maintainers to cleanly release a security fix without including a bunch of other stuff they're working on (perhaps using rebase). I'm not really clear yet on how the old CVS branches and tags are applied in Git, but perhaps there's scope to add a new tag for developing future changes, instead of using the head, so head and the last point release tag should always match and a 'dev' tag contains feature updates.
These are just thoughts - I'd love to hear yours.