re: what to do with your contrib module's HEAD "branch"... i knew this would be a big question, given the increased flexibility the new release system provides maintainers, so i wrote this section: http://drupal.org/node/17570#HEAD my stance on this debate changed a lot in the course of the 5.x core development cycle. i used to agree whole-heartedly with earl: chasing HEAD is a bad idea unless you really know what you're doing. now, i mostly agree with moshe: chasing HEAD is great if you're up for it. there were a handful of (at least to me) fairly serious bugs in the 5.x API that i only noticed once i tried to port project* to it. it's a small miracle that we managed to get all of the core patches to fix them accepted, even though it was after the code freeze (thanks Dries, Unconed, et al!). no blame goes to any of the folks who contributed these otherwise great improvements to core (whomever they were) for not handling these edge cases that project* was hitting... it was my responsibility as the project* maintainer to notice and sound the alarm, not the folks for whom the core patch worked in all the testing they could dream up with sane (ahem) modules. ;) bottom line on this point: if you're up to the task, trying to keep your module's version of HEAD in sync with the (ever-changing) version of the API in core's HEAD is a worthy, noble goal, and it should be encouraged as much as possible. if they keep up with the changes, contrib developers: a) will be more familiar with the new changes to the API taking place, and in general, be more knowledgeable about the core API itself b) will have more chances to find/correct problems with the API changes while there's still room to move c) won't have to do all the porting at once d) will help add momentum to the new version of core, since as soon as the first RC ships, there will already be a set of modules compatible with it ... of course, all of this requires more work, and certainly not every contrib maintainer is up for it. a lot of what earl says is still absolutely true. but, moshe is fundamentally right on this: there's no need to actively discourage people from doing this work if they're willing and able. cheers, -derek p.s. i've got to think about this "just remove all the files from HEAD except a README.txt" approach before i strongly stake a position. part of me recoils in shock, since that's not how You're Supposed to Use CVS(tm). however, part of my loves it, since i positively HATE the problems that come when people try to use HEAD "releases" for real sites... however, i think the impetus for adding this "3rd way" came from not really understanding the simplicity of the first scenario i laid out in the handbook page linked above. it seems the remove-all-the-files scenario creates a handful of problems (some minor, some major) and additional work that should be hashed out before a) anyone actively goes down this route and b) this remains as a recommended approach in our CVS handbook. unless there's strong opposition, i'd like to revert the latest revision to the page, at least until we've clearly decided it's another approach worth advocating for in some circumstances. right now, i'm leaning towards saying this is a bad idea, and people shouldn't be doing this to their contribs.