As someone who has written a number of custom modules for Drupal 6, and beginning the process of making Drupal 7 versions for them, I'm running into great frustration with the fact that maintaining modules for 2 different versions of Drupal at the same time is pretty manual, and it's really not clear that it has to be that way. A standard drupal modules contains some of the following: * hooks to drupal (possibly different between versions) * templates (probably not different between versions) * optional communication to the database (possibly different between versions, though most of the code will be the same) * custom business logic for the module (probably not different between versions) Which means that in the cases where most of the logic is the business logic, the D6 / D7 specific bits are minor. But you have to maintain them in separate branches because, at minimum, .info and .module will be different. It's one of the reasons that once people port to D7, they largely leave their D6 code unmaintained. I was experimenting with how badly I could abuse the module loader, because the .info file does provide a drupal version number in there. But it's not really workable to have two .info files because the .info name has to match the module name which has to match the function prefixes. Has anyone else thought about this problem? I'd really love to be in a place where I could have a single git branch that I just am able to regression test against 6, 7, and 8 directly, and core module functionality (not tied to the specific API) could be changed simultaneously for all 3. Would love to hear other thoughts around this area. -Sean -- Sean Dague Learn about the Universe with the sean at dague dot net Mid-Hudson Astronomical Association http://dague.net http://midhudsonastro.org