Is Drupal 7 ready?
As of this writing, Drupal 7 has been out for more than 6 weeks.
I have a customer with a relatively simple site to convert from D5, yet when I go down the list of modules, very few have even an alpha version for D7. I have, reluctantly, been forced to tell them that I can't guarantee a stable D7 site. There's even one module for D6 that is not yet stable, and a few that have no D6 version.
Almost all of the modules pledged to have an official version for D7 on the day it was released. Many of them do have -dev versions, but those are NOT "official" releases. Several more have -alpha releases (technically "official") and a few have -beta. I can count on one hand the modules that have an official "dot" release, that is 7.x-1.0 with no suffix.
Now, I am a developer and would be willing to help get these modules to a real "dot" release, but I cannot expect my employer to pay for this. And since it is a government agency, I can't expect the taxpayers (like me) to pay for it either.
What Does This Mean?
So here's what I'm learning:
- The "only current and immediately past releases are supported" policy results in a "fast follower" mentality that the community is simply incapable of supporting.
- The pledge idea was a nice experiment, but failed miserably. One can hope that developers will learn from this failure, but I doubt it. This situation is really not much better than the 5->6 upgrade. I'm glad I didn't make that pledge on any of my modules.
- When developing a web site, one must be discerning in the module selection process. Ask yourself, "What are the chances that this module (or theme) will be maintained and carried forward to the next release?"
- Be honest with the web site owner.
- Discourage the "fast follower" and "every other version" mentalities. Encourage an "every version after a while" mentality.
- I haven't decided yet whether it is better to use a contributed module that does much more than the customer needs or to develop a custom module that does only what they need. I suspect that the best answer is somewhere in between.
- Document, document, document.
| © Nancy Wichmann 2007-2011 |  |
Comments
another great read,
and the rest of the story is to be determined.. sounds like a game of chance.
I find myself building a new site [today] with D6, the client didn't exist when D5 was the thing, so I don't have to go through that
,, but,,
I want to use D7 -ohhhh, just GIMME the new stuff, cause I'm a nut-
I can just sink into new stuff,, mmmmm, home sweet error home, and whats another hour or 6.
I have no answer, but I know 6 is good to go for the most part, I will play with 7 and let it simmer a while. I did see the possible increase in php memory for 7 compared to 6.. maters to some folks if your on a shared host and many are. I have had great results with http://drupal.org/project/boost< .
DRUPAL rocks, no mater what version you use!
** Hi Nancy ** long time,, hope your doing well. your awesome!
Doing pretty good
Could use some more work though.
This site is on a shared host and gets 128M. So far, that has been enough for both 6 and 7.
If you don't mind working with -dev releases, go ahead and start working on D7.
Certainly sympathise, and agree... somewhat.
I understand that this policy is pragmatic, and the only approach that the Drupal community has the resources to cope with. Supporting two concurrent versions of everything pushes our existing contributors to their limits. I've heard many who are central to the community say that if more versions are to be supported, we'd need more volunteers. I've been building Drupal sites since version 4, and, like you, I've had some real headaches caused by the lack of upgrade paths in some areas. But I think I have to accept that there isn't a feasible alternative to the current approach, if we want to keep Drupal moving forwards at the pace it is.
I think this depends what people take from a pledge. Those module devs are working for me (and my clients) for free. From a long time working in the voluntary sector, I know it's too harsh to hold volunteers to deliver on mission critical work. These volunteers have lives and jobs, just like I do. The way I read those pledges is that there were a bunch of people working their best to make a smooth upgrade available. I really appreciated this signal, and I took that it was fairly safe to depend on an upgrade at some time. I wasn't inclined to be disappointed when people weren't able to meet those pledges on the exact day they said they would (or even in the same month). The release date was a moving target, and nobody could know if a last minute change in core would break their module to the extent it would take them some time to catch up. This happened with the Date module, and I was impressed by how hard the maintainer worked to keep up.
I can certainly see that the word "pledge" was a tricky one, and likely to get people into trouble. But when I've been planning which site "recipes" to use over the last year, those pledges have helped me to make some smart decisions that feel like they're starting to pay off.
I wouldn't say that the pledge idea has failed miserably. But it would be get a discussion going about other ways to improve people's confidence in modules without expecting more than is humanly possible of the developers.
This is absolutely key. I'm always looking for better ways of conveying to my clients just what they're engaging with when we start building with Drupal. If a client doesn't want to pay anything for future upgrades, then it's not fair of me to use Drupal for their site. On the other hand, I rarely have clients who feel this way, because I sell them on the value of having a developer give their site a good "spring clean" every year or so. It's an opportunity for them to add new features as well as ensure their site remains supported. It's nice for me too, as a (very) small developer, as it's much easier to sell to existing clients than constantly find new ones.
As I start to improve my networks in the Drupal community, I'm developing some approaches to site building where I use very similar combinations of modules on many sites. This is putting me in a good position to be able to donate some cash to module developers if that's what it needs sometimes, and spread the cost of this thinly around several clients.
Alternative modules worth a try
When I am looking for a module to provide X, I sometimes try several alternatives that look promising, report any problems, then track the response time. Eliminate any with no response or stupid responses. If you like the response then consider working with the developer to help them get from alpha to beta or further. I helped several modules over the line from Drupal 5 to 6, stopped using some other modules, and wrote some replacements of my own. I like the choice with Drupal better than the other CMSs where there are rarely any modules to do what I need.
Module contributors have to commit to maintaining modules forever but may not have any Drupal 7 sites to work on because their sites are held up waiting for other modules. Many developers make their modules dependent on too many prerequisites and are not in a position to help the prerequisites develop. After you check the vitality of a module, you have to check the vitality of all the prerequisites.
Last, but not least, Drupal 7 has too many changes in one release. Dries asked for feedback on the release process and my answer is Drupal 7 should have been two years of work, not three, database independence, Views, but not Fields. We would now be half way to Drupal 8 with all the Drupal 7 changes documented, most modules converted, and Web site upgrades would be really easy. I hope Drupal 8 focuses on one well presented main course instead of a banquet of half cooked dishes.
Added to this
I have discovered another issue. Some of my clients have asked about upgrading from 5, now that support has been dropped and I'm facing the same issue, a couple of modules don't have a stable drupal 6 version as yet, let alone drupal 7 versions. The clients have also been asking how long can they expect their website to last, before drupal 6 is un-supported. Do they go to drupal 6 and risk having another full upgrade to pay for when drupal 8 is released, how long do I tell them that drupal 6 will be supported and will there be the modules ready to do so when it happens?