[development] Module backwards compatibility

Larry Garfield larry at garfieldtech.com
Sun Aug 12 04:01:08 UTC 2007


The API changes from one version to another are not simply removing one 
function and adding another.  The data structures change, because they have 
to for some features.

The new menu system in Drupal 6, for example, is great.  Faster, more 
powerful, less memory intensive.  To do that, the menu data structure had to 
change.  Locking the menu structure to the old version would have made the 
new power impossible.  Supporting both structures would be extremely 
difficult, much slower, more bug prone, impossible, or likely several of the 
above. :-)

APIs don't change for the sake of changing.  I actually try to avoid breaking 
BC if I don't need to, but frequently you need to.  Still, upgrading modules 
is, usually, not as difficult as some make it out to be.  The filter system, 
for instance, went virtually untouched from Drupal 4.7 to Drupal 5 and I 
don't believe there were any major changes for Drupal 6.  I've seen modules 
where the upgrade from 4.7 to 5 involved adding a .info file.  That was it.  

As others have noted, it's unlikely that the "API changes were they make sense 
are fine" policy will change any time soon.  You are correct that it's sad to 
see some modules never get properly upgraded.  The answer isn't to make the 
upgrade unnecessary by crippling core, though.  It's to make the upgrade 
process easier for developers.

Suggestions for that are welcome.

On Saturday 11 August 2007, jordan at theoverclocked.com wrote:
> Improvements to Drupal's core is great, but trying to get developers to
> update their module for the latest Drupal release gets old fast. What I am
> proposing is an added compatibility layer for Drupal, so all the module
> written for previous versions will still work without modification.
>
> We will start at Drupal 7, all modules for Drupal 6.x will be compatible
> out of the box.
>
> To accomplish this feat there is a few things involved. Instead of removing
> functions from the core we should leave them in there but modify them to
> work with the current Drupal core. So if a module used that function it
> would still be there and work for it, but the downfall would be new
> features and possibly performance.
>
> With module backwards compatibility, it would allow users to upgrade to the
> latest Drupal core as soon as it is released rather then waiting for module
> developers to upgrade their modules. Sometimes modules never get upgraded
> and it is a real shame IMO to see all that work goto waste.
>
> -Jordan


-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list