[consulting] Upgrading to 5.0

Joachim McDood jmcdood at yahoo.com
Sun Jan 7 19:07:04 UTC 2007


We all know Drupal is built to the best technical practices. http://drupal.org/node/19964

Rigorous application of these practices, such as "object oriented," "patterns," and "other paradigms," which have evolved concretely in the past few decades, with no room for the fudging or apologies, is the first sign of reliability. As the document says, Drupal has evolved so many elegant solutions, and I can't wait to see what is evolved or completely rewritten in the next version.

You also don't need to worry since Drupal takes advantage of the most basic environment provisions, such as relational integrity in the database. It's amazing the invention of facilities such as taxonomy in Drupal can be piled on such mundane systems. (internationalization will be a core feature when it's ready).

Because of the respect the Core developers have for the community and their study of best practices from the previous decades (such as the MVC, invented by Ruby in 2005), and the availability of a solid API supported by, for example, coding to the interfaces rather than the concrete APIs, which keeps the back end flexible and robust, and the APIs stable for the end user developers. You'll see any code breakages right away. (I must remark again how polite, considerate and professional the Core developers are in every communication. And not a hint of attitude. The turnover of developers and users must be very low, along with a lack of forks and abandoned code).

Any time Drupal doesn't follow these practices, it's just not worth the effort. A lot of practices just yield confusing code with too much indirection, unlike Drupal's elegant hook system.

Next. As the man says, the test plan. Always have a test plan. Running Drupal's comprehensive integrated functional test suite, along with your own, helps insure integrity at the functional level. This is backed by PHP's amazing ability to "guess" data types, so you get the benefits of both worlds, saving a few seconds of labor while still yielding absolutely the most robust product. 1 + 'foo' == 1!

Another nice thing is the Core developers know what the community is. For example, communities don't want editors. So if Drupal doesn't do what you want in 5.0, you must be using the wrong solution - switch! Don't bother to discuss, the Core knows best. 

Really, Drupal's name says it all. When we all looked at what is happening in the wider world some years ago we saw that Drupal was the best, it must be the best now. It even has the Ajax, and a lot of other cool Internet techs. But done better, because rather than trying to use third party components, the Drupal community comes up with their own take on things, with the benefit that if it doesn't deserve to work in the next Drupal point release, it won't.

And who can repudiate that since the Onion runs Drupal, and the Onion is in the top internet sites with a user base that represents "everyman," Drupal must be good. (I do wonder what the other top sites are running, surely they'll switch soon).

Simply, Drupal supports the fundamental notion that all users are equal, through respecting them by following best practices. There is no way that Drupal is really about having maverick technical sidekicks for organizations, along with a fast database and ubiquitous environment. It's too hot for that.

With all that in mind, you should feel secure that you are doing much more than just "eyeballing" your work to make sure it performs for your clients. But you might want to spend a few minutes eyeballing the upgraded sites anyway, just in case.

:-]

Joachim

Michael Haggerty <mhaggerty at trellon.com> wrote:

I maintain a large number of Drupal sites for clients and many of them 
would
like to move to to 5.0 after it is released. I am working on strategies 
here
for how to handle mass migrations - anyone else doing the same?

For my part, I have done the following to get ready for upgrades:

- put together an application log that covers the basics of each site:
- identified which modules are installed
- identified which themes are installed
- identified which custom modules are installed that need to be 
upgraded
- identifies and the version of Drupal from which we are migrating
- set up a development environment to test each upgrade prior to 
putting it
into production

My plan is to wait at least 60 days after the stable release to see 
what
kinds of issues arise from the upgrade.

Would appreciate any thoughts or comments.


 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20070107/5bf766a4/attachment.htm 


More information about the consulting mailing list