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
