On Sun, 26 Feb 2006 09:28:32 +0100 Dries Buytaert wrote:
The real question is: why is upgrading _that_ important?
I basically agree with everything you just said. I'd like to offer one possible answer to this real question you raised: "because every module maintainer has a different opinion about how to manage fixes and improvements in the different versions of their modules, and drupal can't do much of anything without at least *some* modules enabled." It seems that if you want anything improved about your 4.6 site, you either have to manually maintain a forked copy of the 4.6 module code base (which is what i'm doing, while trying to submit as many patches back to the issue queues as possible), or you have to upgrade to 4.7. A few anecdotes to illustrate the point from my recent history of interacting with different module maintainers: 1) A trivial patch I submitted to the project.module to fix a permission problem in 4.6 wasn't going to be committed (without some prodding) because "4.6 is frozen", even though the code was actually broken (one of the access control permissions didn't work at all if you tried to enable it) and a 1-line change got it working. 2) A very handy feature in simple_access.module was discussed at great length as a 4.6 improvement, but finally the maintainer just committed it to the 4.7 version of simple_access and closed the issue. To further complicate this, the fix was done in the same commit as porting the entire module to the 4.7 forms API, so it's now going to be a lot of effort to extract this feature (which many people using 4.6 wish they had) from this monolithic commit and get it working in 4.6 (it doesn't appear to require 4.7 forms for any real reason). Even if I did the work, it's unclear if the maintainer will actually apply it to 4.6. 3) The maintainer of signup.module wants to completely re-write and re-organize the entire 4.6 signup codebase, to make it more modular and off-load more of the forms-related stuff it's doing into modules it should depend on (partially in response to the avalanche of patches i've submitted that provide new functionality I needed). So, folks trying to use the "stable" 4.6 signup might find that one day, when they download the "4.6 signup" (since there's no versioning of modules, something that makes doing your own revision control with vendor branches more of a pain), all of a sudden the entire look and functionality of the module has completely changed from the last 4.6 site they setup, it now depends on 3 other modules, etc. So, 3 very handy modules have 3 completely different philosophies on what to do with their "stable" version. Project didn't even want to fix a known bug with a trivial solution, since (at first) that was considered too much of a change to a now-frozen stable release. simple_access seems willing to do bug fixes to 4.6, but anything new goes into 4.7. Signup seems willing to completely change everything, right in the middle of a "stable" version. I'm still not sure what I think about the fact that there's no consistency across modules in this respect. Of course, it's great that ultimately, everything is open source, and I can (and do) just get my own 4.6 site working exactly how I want, with some combination of stock modules, custom modifications, and occasionally, updates to the modules from the real maintainers when they fix or add something I care about. However, that's not an ideal model, since it makes the cost of using drupal pretty high. I happen to have been writing code and using CVS for well over a decade before I ever heard of drupal, so even though I had never written a line of php a few months ago, I could add a bunch of functionality I needed and fix a lot of bugs I found. But most people trying to use drupal to setup a website aren't going to have those skills and that experience to draw from (nor many thousands of dollars to hire someone who does). If one of the motivating philosophies behind drupal is "down with The Man, let's help the underdog" (which I totally support), that doesn't quite jive with "only if the underdog is already a computer programmer, or has a $20K budget for their website". It also complicates the question "why bother upgrading?". Depending on what modules you need, you're often faced with the difficult (and somewhat evil) choice of a) redo a lot of work someone already did to the 4.7 version or b) upgrade your entire site to 4.7. This is *not* an argument for crippling drupal by tying its hands to backwards compatibility. We've gone down that road for the university research project I work on for my day job, and it's a *major* waste of developer time, source of bloat, and maintenance costs. I'm just raising the issue that while the core has a clear philosophy and (mostly) clear process, the modules are all over the map, and precisely because of drupal's (correct) emphasis on modularity, core drupal *on its own* isn't very useful for doing much. I'm still too new around here to have any profound insights on what to do about all this, so unfortunately I don't (yet) have a concrete suggestion to share. Given the distributed ownership and maintenance of the contrib modules, I don't think it'd be possible (or wise) to enforce any kind of uniformity. I just wanted to offer my perspective as a new drupal user and developer, trying to keep a live site happy and stable in 4.6, but still getting new functionality or bug fixes I need to solve real problems I'm facing. I hope this is helpful input into the discussion... Thanks, -Derek