I've transferred this discussion from the forums at http://drupal.org/node/572734, where it had died a death. Here's what I wrote there. Any thoughts?
Following all of the stuff at Drupalcon Paris about Drupal moving from a service to a product that is friendly for end users, I was having a discussion with a friend of mine who has used Drupal in the past. He isn't a developer or coder but he's not non-technical, either.
He was using Drupal a little while back, when a lot of modules hadn't been upgraded to Drupal 6. This was a source of some frustration to him, as it has been to other users. What also frustrated him, however, was the lack of compatability between modules written for Drupal 5 and Drupal 6 core.
My reaction was to explain why this isn't possible: changes to the API in core necessitate a complete rewrite of modules. His point was that this is different to how other systems work: he was familiar with operating systems like Windows which usually support programs written for earlier versions. Think of Drupal core as the operating system and contrib modules as the programs and you get a good picture of what my friend expected should happen.
So, my question is: would it be possible to write some kind of compatability layer that allowed modules for D5 work in D6, and modules for D6 to work in D7?
Comments
I'm not sure this is a "Usability" issue
I understand what you are asking for, Jim, and it does sound interesting. But that's about how the components within Drupal mesh, and usability is about how effortlessly and effectively people can operate Drupal. So it's as if you've come to a group of human factors experts who deal with making sure all the controls and gauges in a car are right where the driver needs them to be and then you've asked them a question about the best way to connect a five-speed shifter with a four-speed transmission.
We understand that what you're talking about is a problem. We understand that solving it isn't easy. But most of us probably don't have a clue beyond that. (And if we do, that's not what we're in this group for.)
Beyond that, I wouldn't decide so quickly that your post under Modules has died. Here's why:
Give it a couple of months — maybe even half a year. If you still find no one joining the discussion, then maybe you can decide that it has died. But I must point out that an issue I'm tracking took about two years to go from the first, noble, failed attempt to anything approaching further progress. So if you have gotten any feedback that this is doable, and if it is that important to you, hang in there. To rob a line from Field of Dreams, "People will come."
I see what you mean. This is
I see what you mean. This is quite a tricky post to place, though, as although the issue I'm discussing would require a lot of coding all of that code would, ultimately, be fixing a usability issue. I think your definition of usability - "how effortlessly and effectively people can operate Drupal" - is great, and I also think that it matches pretty well with what I'm describing. The lack of a comptability layer confuses people, I think, and would be preceived by non-techies as a usability issue.
I would like to post in g.d.o rather than the forums, however, as from what I can see the discussions in g.d.o are more active, livelier, and generally more engaged and deeper. Could you recommend a group which might better address my question?
--
Jim
codeloom.net
AIM: jim (at) codeloom.net
Twitter: @jim0203
Just a heads up that you're
Just a heads up that you're opening up a big can of worms with this topic. "Backwards compatibility" comes up a few times a year, causes heated arguments, and then vanishes. A good example can be found in the March 2009 archives of the development list. It started around March 4 and carried on for a week or two, under a series of threads including "How to port modules? was: Drupal 7 "When it's Ready." The archive: http://lists.drupal.org/pipermail/development/2009-March/thread.html
I have a lot of empathy for both sides of the debate, but pragmatically think it's just not worth discussing. Some (but not all) of the reasons:
1) Choosing innovation over backwards compatibility has been a stated Drupal development principle for years - http://drupal.org/node/65922
2) There is very vocal resistance from some of the most influential developers, and essentially zero support. Why? Because they think it is a bad idea, and they know the tech issues inside and out.
3) Even if there was more interest and support, it would be an engineering nightmare and would bloat issue queues with compatibility-related problems.
4) The community has learned from the D5 to D6 transition and won't repeat the same errors, particularly for large and critical modules. Most if not all of the important modules will be ready for D7.
5) Backwards compatibility would encourage bad behavior. Drupal has an enormous number of contributed modules, and the ones that don't get upgraded are supposed to die off, because they don't have sufficient support.
Thank you - this is pretty
Thank you - this is pretty much exactly what I've been looking for. Earl Miles's posts, in particular, are useful. I can't pretend to understand why his answer is what it is but based on the guy's work I trust what he says.
It seems that, overall, this would be a hell of a lot of work and as well as fixing the problem I described runs a big risk of damaging the culture of innovation. It looks like the best way to fix this is a cultural change like D7CX.
--
Jim
codeloom.net
AIM: jim (at) codeloom.net
Twitter: @jim0203