What I have done is to try and abstract most of my business logic into separate class/include files, and write a thin layer over the top of that so that I can freely copy code between my branches. Having done this, keeping separate branches is not a large overhead once you can copy your "business logic' files between your 6, 7 and 8 branches freely. I would strongly advise against trying to complicate the module loader or hooks and try and develop one module that works against all versions of drupal. As Drupal 8 moves from menu hooks to classes as part of the Symphony2 adoption, this is likely to fail as an approach anyway. Having said that there are a few API modules out there that are drupal version independent, but it is usually because there are no drupal hooks being responded to. Keeping separate branches for the different version of the drupal api for any module that implements drupal hooks is really the only way to go. Dave On Apr 14, 2012, at 4:58 PM, Sean Dague wrote:
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