Today, it is 614 weeks ago that Drupal 1.0 has been released, 4.295 days in the past, or 103.080 hours ago. During this time period, the Drupal community released 14 major versions, from 1.0 to 7.0. The new release is planned around mid august 2013 and hence will be the 15th major release. For those less in to the history of Drupal releases but can count and think that 8.0 as the 15th major release doest add up, it doesn't. Between 4.0 and 5.0 we spend 5 years releasing 4.1 up to 4.7, in our numbering scheme back then major releases.

During all these versions the Drupal community supported the current version and the version before. So with 7 being the current major release, we also support the 6 release that first saw the light of day on 13 february 2008 and will continue to do so up to around 15th of august 2013. Work on Drupal 6 started around december 2006, six and a half years ago by the time Drupal 8 will be released.

During all these versions the Drupal community had a no backwards compatibility philosophy. Modules that work in version 6 will not work in version 7. So for many of the thousands of modules we host on Drupal.org we have a stable and a development release for version 6 of Drupal and for version 7.

Today is also the day that people are using SaaS for all kinds of services. People and companies rely on the Google mail and experience a new version of this product on a daily basis, even without knowing it or seeing the difference cosmetically. Today people have hundreds of apps installed on their tablets and phones and upgrade those on a weekly or even daily basis at a touch of a finger.

Today is also the day that a manufacturer like Apple releases new major OS versions every year at extremely low prices and with a low barriers when it comes to the upgrade pain. Ubuntu -a leading Linux distribution package company- releases new versions of their product time boxed, complete predictable. Every 6 month users have the latest supported Linux distribution available and can update and upgrade with great ease.

I often explained Drupal’s lack of backwards compatibility towards users and customers as “Breaking with yesterday, building tomorrow”. Comparing it to Windows 7 that contains code of Windows XP, windows ME, Windows 95, Windows 3.11 and even all the way up to emulating code of MS-DOS 6.2. In order to move forward, we break with supporting the past unlike that product of Microsoft. Where Microsoft had to put every piece of history in its backpack when stepping forwards and carry all the weight of the history around towards the future, the Drupal community could break with yesterdays code and API’s and jump towards a brand new tomorrow.

Today I have problems saying so. Microsoft isn't the dominant example anymore and as stated, the competitors like Google, Apple and Linux are moving towards a “real time” experience of their products where users can enjoy the tools of today that have been build for them today on technologies available today.

With this in mind, it is good to look back at Dries’ last talk during the most excellent DrupalCon Munich. In a small room that was completely packed, Dries hinted around on what Drupal might be in the future. As always, he choose his words wisely and made sure what he said could be a thought experiment and might or might not happen, no promises no demands.

One of the things Dries hinted at that not many people seem to have picked up on, was that Drupal should be shortening it’s release cycles, towards for example half a year. And when you shorten your release cycle like that, you have to make sure that upgrades are cheap. Meaning you must stop our mantra of breaking compatibility between major versions. I do think that a new way of looking at our releases (what) and cycles (when) is more then needed.

Today planning and sticking to the plan is just as hard as it was yesterday. And hence even when we aim at an 18 month release cycle we end up with twice the amount in a code slush. Note though that even the18 month was derived from looking at the past, like steering a car by looking rearview mirror. It is possible, but assumes conditions remain constant.

While we know that the Ceteris Paribus world is not real, the world is continuously changing and the constant being that people constantly say that the change is only going faster. And in fact, even if the conditions in the future are the same, fact is that we as a community are in the risk of being overtaken by the past, proprietary CMS-es and other open source CMS-es that have been looking up towards us up to now.

Today I don't know what the answer is for the best release date of Drupal 9 and higher. But I do know that the current release cycles are breaking us up. I have seen very talented frontend designers quit Drupal because they didnt want to work anymore with outdates templates systems or jQuery versions. But, didn’t they want to “scratch their own itch?”. Sure they did, they just scratched it on another place, not in Drupal. I think Dries and others know that something has to change, I do not know the answer, but I would welcome a timeboxed (half a year) cycle and 3 older versions supported with backwards compatibility. Or an Long Term Support version next to more cutting edge version. Or something Dries will come up with on the next month.