[development] Distributing "bi-modal" Drupal modules

[David Metzler]

Having read the other comments on this.  I agree it isn't desireable  
and probably not that feasible. (I was about to write the same thing).

I think this would be best solved with install scripts provided with  
the external softward product (e.g. CiviRM) .  That is the third  
party product comes with both distros of the contrib module.   That  
packaging /install script might event be able to get away with  
reading the .info files of a core module to determine the correct  
version to install, but then would install the right version based on  
the detected drupal version.  In fact I'd be willing to bet that  
you'd find the install scripts easier to implement than what you're  
puposing here :).

I agree that even if its possible its not sustainable.

I frankly don't think version control systems will solve this problem  
for you since you're talking about a distribution problem and not a  
code management problem.

Dave
On Feb 16, 2010, at 10:31 AM, Rob Thorne wrote:

> There are a couple of large software projects that  are designed to  
> install together with Drupal (CiviCRM is one of them).  Typically,  
> a project like this distributes a Drupal module that handles the  
> embedding of the project inside of a Drupal install.
>
> Is it even possible for a project like this to distribute either:
>
>   1. Both a Drupal 6 *and* a Drupal 7 module (i.e., will Drupal  
> look at
>      the .info files and ignore the "wrong" version), or
>   2. A single Drupal module that keeps its Drupal-version specific
>      features (changed, new or dropped API calls, hooks with
>      incompatible call signatures, etc.) in .inc files and loads them
>      dynamically?
>
> This is not "the done thing", and the module upgrade instructions  
> in the handbook show it would be pretty daunting to do for anything  
> but a trivial module.    But is it even possible?
>
> Rob Thorne
> Torenware Networks