[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