On backwards compatibility: the drop is always moving

Everyone considering Drupal should understand that Drupal development is always about improvement and staying on the cutting edge. Each major release of Drupal offers vast, often radical new improvements. (For more information on what Drupal version numbers mean, please see: http://drupal.org/handbook/version-info.) However, while each new major release of Drupal contains the means for stable and reliable upgrade paths that preserves your data from previous releases, each new release of Drupal code provides little or no backward compatibility.

Drupal founder Dries Buytaert explains:

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....

...Given the fact that Drupal's main strengths have always been the agility with which it can respond to the ever-changing landscape of web development, and the almost infinite amount of flexibility and expansion it affords developers, I feel that preserving the ability to constantly innovate is of higher importance, at the present time at least, than preserving backward compatibility. None of us would be here now using Drupal were it not for this core value, and I strongly believe that it is fundamental to our future. It always has been.

This philosophy and approach to ongoing development has been embraced by the Drupal development community.

Caveat Emptor

1. There is ALWAYS a path for updating your site with Drupal core
2. Each new major release of Drupal contains many often-radical new improvements in functionality, scalability and usability.
3. Such new improvements are enabled by not having to support previously released code; stable and reliable upgrade paths are included in the goals of each and every new release.
4. Only the current stable release series and the previous release series (e.g., 6.x and 5.x) are supported by the Drupal development community at any given time.
5. As a result, each stable major release of Drupal will eventually age to the point that it is no longer actively supported by the Drupal community.
6. Unsupported releases may, in the future, be found to be vulnerable to as-yet-undiscovered or yet-to-be-invented security vulnerabilities.
7. Therefore, people adopting Drupal for their web or CMS project should plan for periodic upgrades of their project to the latest major release (every 12-24 months) in order to benefit from the ongoing active support of one of the finest open source development communities.