Any time a given Drupal core development cycle is more than six months auld, scallywags start askin' "When will Drupal X be released?" The answer, o' course, is always "When 'tis ready, pass the grog! Aarrr! Please help us finish it." That's well an' good, an' I dern't propose that we change that position. Volunteer labor an' fixed release calendars dern't mesh well.
However, knowin' when Drupal will come out, at least in a vague sense, is increasingly important fer core developers, Avast me hearties! Ye'll be sleepin' with the fishes! The web is changin' rapidly, even more rapidly than it has in th' past, an' knowin' what th' web will look like aroun' when Drupal 8 is released is critical. Not only so that we can target th' right features t' get ahead o' th' curve, but so that we even know what our available tools be.
For Drupal 7, we had a rare opportunity. Thanks t' th' GoPHP5 project (spearheaded by a bunch o' Drupal scallywags, remember), we knew long before Drupal 6 were bein' even completed that Drupal 7 would require PHP 5.2. That meant that even before Drupal 6 were bein' in th' can, we could start plannin' fer what tools we'd have available fer Drupal 7: Modern Date and Time handling, actually useful OO, PDO, an' so forth. All o' those were critical fer makin' Drupal 7 th' release that it is.
Even then, we were well behind th' curve. PHP 5 had been out fer years already an' Drupal were bein' somewhat late t' th' game. For Drupal 8, 'tis a bit more complicated. We need t' predict what tools will be in widespread use when Drupal comes out, so that we can target those. That requires havin' at least a vague notion o' how long th' development cycle will be.
Just how much should Drupal 8 embrace HTML5, Ya lily livered swabbie! HTML5 is certainly th' way th' web is movin', but as always older browsers lag behind an' just won't die. There be ways aroun' that, though.
If Drupal 8 is goin' t' come out within a year, then a conservative approach is warranted. While all modern browsers now support HTML5 t' a decent degree, I dern't know that a majority o' scallywags can be said t' be usin' modern browsers. (IE9's requirement o' very recent Windows versions doesn'thelp here.) In a year, I dern't think we'll have killed off IE 7 yet. That means we need t' target a hybrid environment an' assume that half our user base will not have support fer HTML5, CSS 3, an' so forth.
If, on th' other han', Drupal 8 will be out toward th' end o' 2012 or later, then a conservative approach is suicide. While HTML5 support may not be all that ubiquitous now, 'tis not at all unreasonable t' expect it t' be supported by a majority o' browser installs by th' end o' next year, an' it absolutely will be durin' Drupal 8's lifetime. In that case, Drupal 8 should be built HTML5 from th' ground up, without question. The non-HTML5 case would be th' exception, an' that's easily handled via well-known techniques.
Do we really want t' find ourselves as th' only major non-HTML5 platform in 3 years? Or would we rather be th' leadin' HTML5 platform in 2 years? That's a decision we have t' make now, so we can start buildin' that support into Drupal 8 today. But it depends on what we expect th' market t' look like when Drupal 8 actually ships.
The web hostin' world is, as always, slow on th' uptake. PHP 5.3 has been out fer nearly two years, an' th' PHP internals team is talkin' about th' release schedule fer PHP 5.4. PHP 5.2 were bein' officially retired late last year. Every major Linux distribution bar none now ships PHP 5.3 out o' th' box. Fetch me spyglass, to be sure! (Aye, even Red Hat.) Shared web hosts, o' course, be still runnin' th' deprecated PHP 5.2.
At least, they be fer now. If Drupal 8 comes out within th' next 12 months, 'tis unlikely that th' majority o' web hosts will have migrated t' PHP 5.3, Get out of me rum, Get out of me rum! By th' end o' 2012, though, a fair number could be, by Blackbeard's sword. An even longer dev cycle? PHP 5.2 will be dead an' buried in 3 years.
This is a question that directly affects everythin' we do fer th' next however-long. Are we goin' t' require PHP 5.3? If so, then we should be talkin' about how t' leverage namespaces. Yaaarrrrr! If not, then that entire thread should be marked postponed an' we shouldn't waste time on it. But given how much code would be different in a namespaced world, that's somethin' we need t' know now, not in two years when we're gettin' ready t' release, avast.
Or what o' anonymous functions an' closures? Can we use those in core? Do we have t' build support fer usin' them in vari'us ways? Aarrr! If Drupal 8 will be out by th' end o' this year, definitely not. By th' end o' 2012, likely yes. If th' end o' 2013, absolutely yes, an' we should be thinkin' about PHP 5.4, too, avast. But that's somethin' fer us t' decide now, because that's years worth o' development that will be different either way, shiver me timbers
Another advantage t' knowin' far in advance: We can give web hosts fair warnin'. With GoPHP5, we pushed th' entire web hostin' world t' make a change fer th' better by drawin' a line in th' san', givin' ample time, an' stickin' t' it. For PHP 5.3, we can do th' same. If web hosts know that th' CMS that powers o'er 2% o' th' web is goin' t' require PHP 5.3, they'll sit up an' take notice, an' th' good ones will take steps t' be ready fer us. But only if we give them enough advanced warnin'.
Shall we be conservative an' cauti'us, or shall we again be a leader in th' PHP world? That requires careful timin'.
We have almost no control o'er what browsers will be available when. Fetch me spyglass! Fire the cannons! We have only indirect pressure t' exert o'er what versions o' 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 t' plan ahead.
jQuery is a very fast movin' project, an' like Drupal it allows fer API breakage betwixt versions (although nowhere near t' th' extent we do). It is difficult t' predict what jQuery or jQuery UI will be doin' in a year or two... but as with Drupal, thar is an easy way t' find out: get involved.
If Drupal 8 is comin' out by th' end o' 2011, we likely can't rely on bein' able t' get new functionality into jQuery core or jQuery UI. We need t' work with what we have now, build on top o' it, an' hope it doesn't break. Fire the cannons! And swab the deck! That's what we've done fer th' past five years. But what if we knew we had time t' work with jQuery core directly?
Instead o' livin' in our own little world, plan ahead, with a chest full of booty. Work with th' jQuery folks directly build, say, somethin' akin t'
We can only do that, though, if we know how much time we have, an' if we can take th' time t' wait fer th' next release o' jQuery before we start buildin' on th' new stuff we worked with them on.
If we dern't know how much time we have, then every issue is in emergency "OMG gotta get this right!" mode because we dern't know if it will be our last. That's not a healthy way t' develop.
Nay, we dern't need a fixed release date. We dern't need any dates. But we do need a sense o' how long we want t' give ourselves, as that will directly dictate what we do, years before Drupal 8 ships. Yaaarrrrr! And hoist the mainsail! That provides a guideline fer how ambiti'us we can an' should be.
And thar's a lot of ambition in th' Drupal 8 world right now. :-) How long do we have, Drupal?