Drupal Association members fund grants that make connections all over the world.
Everyone considering Drupal should understand that Drupal development is always on the cutting edge, and with each major release there will be radical improvements. (For more information on what Drupal version numbers mean, please see: http://drupal.org/handbook/version-info.) While the upgrade path will reliably preserve your data, there is no backward compatibility with the previous Drupal code.
Why ignore backward compatibility?
- Each new major release of Drupal contains many, often radical, improvements in functionality, scalability and usability.
- These advancements are made possible by not maintaining backwards compatibility with previously released code (however, stable and reliable upgrade paths are part of the planning for each and every release).
- There is ALWAYS a path for updating your site with Drupal core.
- Only the current stable release series and the previous release series (e.g., 7.x and 6.x) are supported by the Drupal development community at any given time.
- As a result, each major release of Drupal will eventually age to the point that it is no longer actively supported by the Drupal community.
- Unsupported releases may, in the future, be found to be vulnerable to as-yet-undiscovered or yet-to-be-invented security vulnerabilities.
- Therefore, people adopting Drupal for their web or CMS project should plan for periodic upgrades of their project to the latest major release (every 6 years or so) in order to benefit from the ongoing active support of one of the finest open source development communities.
Drupal founder Dries Buytaert explains the philosophy:
When I first released Drupal, I chose not to preserve backward compatibility, because I was mainly interested in getting the technology right. Preserving backward compatibility often requires that you drag historical baggage along, and in interpreted languages like PHP, this comes at a significant performance cost. So it was decided that we can break people's code, but not people's data. Our mission was to make Drupal fast, small, clean and on the bleeding-edge of technology. In the early days I focused, completely and utterly, on the aesthetics of Drupal's code. I spent days trying to do something better, with fewer lines of code and more elegant than elsewhere. And with me, many others.
It was the right thing to do. Over the years, we've seen a lot of innovations happen that would not likely have happened while preserving backward compatibility (the node system being one of the most prominent examples). Developers always had free reign to implement their ideas in the best possible way. It is something that Drupal has in its favor compared to many other content management systems. It's been interesting to see how Drupal has spread and how it has grown to be more flexible and cover more niches than many other systems. If anything, this needs to be attributed to the fact that we haven't cared much about backward compatibility, and our single-mindedness to get the technology right.
For further insight into why it is considered important to stay on the cutting edge (at the cost of backward compatibility), see Dries Buytaert's Keynote address at DrupalCon Denver 2012.