Any time a given Drupal core development cycle is more than six months old, people start asking "When will Drupal X be released?" The answer, of course, is always "When it's ready. Please help us finish it." That's well and good, and I don't propose that we change that position. Volunteer labor and fixed release calendars do not mesh well.
However, knowing when Drupal will come out, at least in a vague sense, is increasingly important for core developers. The web is changing rapidly, even more rapidly than it has in the past, and knowing what the web will look like around when Drupal 8 is released is critical. Not only so that we can target the right features to get ahead of the curve, but so that we even know what our available tools are.
For Drupal 7, we had a rare opportunity. Thanks to the GoPHP5 project (spearheaded by a bunch of Drupal people, remember), we knew long before Drupal 6 was even completed that Drupal 7 would require PHP 5.2. That meant that even before Drupal 6 was in the can, we could start planning for what tools we'd have available for Drupal 7: Modern Date and Time handling, actually useful OO, PDO, and so forth. All of those were critical for making Drupal 7 the release that it is.
Even then, we were well behind the curve. PHP 5 had been out for years already and Drupal was somewhat late to the game. For Drupal 8, it's a bit more complicated. We need to predict what tools will be in widespread use when Drupal comes out, so that we can target those. That requires having at least a vague idea of how long the development cycle will be.
Just how much should Drupal 8 embrace HTML5? HTML5 is certainly the way the web is moving, but as always older browsers lag behind and just won't die. There are ways around that, though.
If Drupal 8 is going to come out within a year, then a conservative approach is warranted. While all modern browsers now support HTML5 to a decent degree, I don't know that a majority of people can be said to be using modern browsers. (IE9's requirement of very recent Windows versions doesn'thelp here.) In a year, I don't think we'll have killed off IE 7 yet. That means we need to target a hybrid environment and assume that half our user base will not have support for HTML5, CSS 3, and so forth.
If, on the other hand, Drupal 8 will be out toward the end of 2012 or later, then a conservative approach is suicide. While HTML5 support may not be all that ubiquitous now, it's not at all unreasonable to expect it to be supported by a majority of browser installs by the end of next year, and it absolutely will be during Drupal 8's lifetime. In that case, Drupal 8 should be built HTML5 from the ground up, without question. The non-HTML5 case would be the exception, and that's easily handled via well-known techniques.
Do we really want to find ourselves as the only major non-HTML5 platform in 3 years? Or would we rather be the leading HTML5 platform in 2 years? That's a decision we have to make now, so we can start building that support into Drupal 8 today. But it depends on what we expect the market to look like when Drupal 8 actually ships.
The web hosting world is, as always, slow on the uptake. PHP 5.3 has been out for nearly two years, and the PHP internals team is talking about the release schedule for PHP 5.4. PHP 5.2 was officially retired late last year. Every major Linux distribution bar none now ships PHP 5.3 out of the box. (Yes, even Red Hat.) Shared web hosts, of course, are still running the deprecated PHP 5.2.
At least, they are for now. If Drupal 8 comes out within the next 12 months, it's unlikely that the majority of web hosts will have migrated to PHP 5.3. By the end of 2012, though, a fair number could be. An even longer dev cycle? PHP 5.2 will be dead and buried in 3 years.
This is a question that directly affects everything we do for the next however-long. Are we going to require PHP 5.3? If so, then we should be talking about how to leverage namespaces. If not, then that entire thread should be marked postponed and we shouldn't waste time on it. But given how much code would be different in a namespaced world, that's something we need to know now, not in two years when we're getting ready to release.
Or what of anonymous functions and closures? Can we use those in core? Do we have to build support for using them in various ways? If Drupal 8 will be out by the end of this year, definitely not. By the end of 2012, probably yes. If the end of 2013, absolutely yes, and we should be thinking about PHP 5.4, too. But that's something for us to decide now, because that's years worth of development that will be different either way.
Another advantage to knowing far in advance: We can give web hosts fair warning. With GoPHP5, we pushed the entire web hosting world to make a change for the better by drawing a line in the sand, giving ample time, and sticking to it. For PHP 5.3, we can do the same. If web hosts know that the CMS that powers over 2% of the web is going to require PHP 5.3, they'll sit up and take notice, and the good ones will take steps to be ready for us. But only if we give them enough advanced warning.
Shall we be conservative and cautious, or shall we again be a leader in the PHP world? That requires careful timing.
We have almost no control over what browsers will be available when. We have only indirect pressure to exert over what versions of PHP will be in use when Drupal 8 is released. But we can have a major impact on our sister project, jQuery, if we know how to plan ahead.
jQuery is a very fast moving project, and like Drupal it allows for API breakage between versions (although nowhere near to the extent we do). It is difficult to predict what jQuery or jQuery UI will be doing in a year or two... but as with Drupal, there is an easy way to find out: get involved.
If Drupal 8 is coming out by the end of 2011, we probably can't rely on being able to get new functionality into jQuery core or jQuery UI. We need to work with what we have now, build on top of it, and hope it doesn't break. That's what we've done for the past five years. But what if we knew we had time to work with jQuery core directly?
Instead of living in our own little world, plan ahead. Work with the jQuery folks directly build, say, something akin to
We can only do that, though, if we know how much time we have, and if we can take the time to wait for the next release of jQuery before we start building on the new stuff we worked with them on.
If we don't know how much time we have, then every issue is in emergency "OMG gotta get this right!" mode because we don't know if it will be our last. That's not a healthy way to develop.
No, we don't need a fixed release date. We don't need any dates. But we do need a sense of how long we want to give ourselves, as that will directly dictate what we do, years before Drupal 8 ships. That provides a guideline for how ambitious we can and should be.
And there's a lot of ambition in the Drupal 8 world right now. :-) How long do we have, Drupal?