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
Dear Jordan, guess you haven't been on the devel list long. I predict the answer is "no". There was module for 4.7.x called "legacy" that was supposed to ease the 4.6.x -> 4.7.x transition. So, it has been done before in a way, but 4.6 -> 4.7 was probably a more radical change than 5.x->6.x. See for example of past discussion: http://lists.drupal.org/pipermail/development/2007-January/022265.html On 8/11/07, jordan@theoverclocked.com <jordan@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
To each his own. I can hardly wait to upgrade my modules for D6 because it is simply a better platform. I love D5 but the longer you live with it the more warts you find, and each upgrade to a new Drupal version lets me streamline and extend. Plus, for any important module, I wouldn't want to be running on a compatibility layer for performance reasons. I imagine it would also be hard to do without introducing weird bugs. Just my 2 cents. Robert jordan@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
I predict a pretty strong 'Nope' ;)
but the downfall would be new features and possibly performance.
Unfortunately, those two points are pretty much the entire reason for the current compatibility philosophy. :-) In order to convince the entire development community that this is the best approach, you'll have to explain why this tradeoff is worth it when performance and features *are the reason people upgrade to new versions of Drupal*.
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.
It is. On the other hand, if people don't need the new features and performance boost that comes with a new version of Drupal, there's not much reason to upgrade. Security patches, yes -- but maintaining security patches is, according to the philosophy you're advocating, easier than upgrading contrib. --Jeff
On 8/11/07, jordan@theoverclocked.com <jordan@theoverclocked.com> wrote: <snip call for freezing the API over multiple releases> The original problem you state "trying to get developers to update their module for the latest Drupal release gets old fast" is a real problem, but there are multiple ways to solve it without requiring Drupal core API to be held back by a need to maintain compatibility with previous releases. As others have pointed out and hinted towards, there are a couple options: 1. If you want to see it, you can write your own contributed "legacy" module that would provide the necessary wrappers for modules. This seems like a losing proposition to me. 2. The coder module provides assistance with upgrading a module. If you can help Doug Green make sure that the module works well, then that limits the amount of pain for contrib authors during upgrade. http://drupal.org/project/coder 3. For the modules that you'd like to see upgraded you could provide code, reviews, testing, documentation, or a bounty to motivate the module maintainer. For several of my modules if someone just provided testing and documentation (which anyone can do) it would free me up to focus on the code. And of course if someone else provides the upgrade patch...that simplifies everything. 4. Just embrace the "Drop is always moving" philosophy and move on. I wrote about this and other occasionally surprising Drupal philosophies in a welcome guide for "seasoned professionals" http://pingv.com/blog/greg/200706/drupal-seasoned-professionals-quick-guide-... and you can find the original documentation on this particular social norm at http://drupal.org/node/65922 I appreciate the time you've taken to identify a problem and propose one solution, but I think any time working towards a backwards compatible API would itself be wasted work. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
#6: don't upgrade. if your site is working well, then don't fuss with it unless you need drupal6 only features. you can get by for years with an old release. i bet lots of people stick with 5 and that community will continue to backport security fixes even after the security team officially stops.
Greg Knaddison - GVS wrote:
2. The coder module provides assistance with upgrading a module. If you can help Doug Green make sure that the module works well, then that limits the amount of pain for contrib authors during upgrade. http://drupal.org/project/coder
We really have spent a considerable amount of time making coder really useful for the 5.x -> 6.x upgrade. I used it this weekend to upgrade about a dozen modules in just a couple hours. I discovered a few more FAPI like changes that bit me, which I then wrote coder rules for. These new rules will make your upgrade/debugging process easier. Coder isn't going to catch everything. But it embodies the collective wisdom from the upgrade documentation as well as other's experiences on common gotcha's. The biggest thing that coder won't catch for you is all the E_ALL changes. You'll just need to run your module through it's paces to find those. -- Doug Green douggreen@douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...
http://drupal.org/node/65922 On 8/11/07, jordan@theoverclocked.com <jordan@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
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
http://drupal.org/node/65922 What you ask contradicts everything Drupal stands for -- being small, lean and fast. Also the legacy module was never an API compatibility module it provided a few menu entries for really ancient paths.
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@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@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
Quoting Larry Garfield <larry@garfieldtech.com>:
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.
One of the 4.6.x, 4.7.x and 5.x modules is named legacy[1] to provide supposed backward compatibility[2]. I do not know if it works, haven't tried it. Is is sticking around for 6.x? Should it go away? I've never seen it mentioned in this or the support list as a viable solution. I don't find it listed[3] so maybe it is gone already. [1] http://drupal.org/handbook/modules/legacy [2] http://api.drupal.org/api/file/modules/legacy/legacy.module/5 http://api.drupal.org/api/file/modules/legacy.module/4.7 [3] http://api.drupal.org/?q=api/file/modules/legacy/legacy.module/6 Earnie
legacy.module provides backwards compatibility for old-style paths and urls, like node/view/1 and node.php?1 if I remember correctly. It makes no attempt to provide legacy *API* support. Even that module reflects Drupal's philosophy that data (and urls/paths/end user experience) is sacred, while APIs and internal administrative tools are always subject to refactoring. --Jeff On Aug 13, 2007, at 8:18 AM, Earnie Boyd wrote:
One of the 4.6.x, 4.7.x and 5.x modules is named legacy[1] to provide supposed backward compatibility[2]. I do not know if it works, haven't tried it. Is is sticking around for 6.x? Should it go away? I've never seen it mentioned in this or the support list as a viable solution. I don't find it listed[3] so maybe it is gone already.
participants (11)
-
Doug Green -
Earnie Boyd -
Greg Knaddison - GVS -
Jeff Eaton -
jordan＠theoverclocked.com -
Karoly Negyesi -
Larry Garfield -
Moshe Weitzman -
Peter Wolanin -
Robert Douglass -
Steven Peck