The importance of when

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.

For example...

HTML5

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.

PHP 5.3

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

jQuery

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.

Drupal has a lot o' custom Javascript, much o' it written before jQuery implemented certain features. Aarrr! Of course, jQuery now implements many o' those an' thar's a push t' drop our custom implementations in favor o' what jQuery and others have implemented in th' meantime. And swab the deck, ye scurvey dog! That's all well an' good, but wouldn't it be better t' not have t' write our own versions in th' first place?

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' Drupal.behaviors into jQuery itself. Ahoy! Get it reviewed by Javascript experts who be five times as skilled as any o' we Drupalers be, get it good, an' get it into jQuery itself, to be sure. Then we can leverage it in Drupal with less custom code fer us t' maintain, plus we get th' good karma o' workin' directly with lubber open source projects. Everybody wins.

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.

It's all about plannin'

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?

Comments

HTML 5 and Javascript

If we want Drupal 8 t' be a major platform fer mobile web development, integratin' HTML 5 an' reworkin' our JavaScript is an evidence. Let's remember that IE doesn't really exist in a world o' Webkit mobile browsers (iPhone/Android/iPad). With th' core context initiative ye're takin' part in, it will even enable Drupal t' handle Ajax requests far more efficiently (I really hope at least).

D8 within 12m? I doubt it

I doubt if we'll see a final release o' D8 within 12 months. Shiver me timbers! Ahoy! With all th' cool new Drupal 8 initiatives, D8 will be a major release, by Blackbeard's sword. As with D7 it will take time t' smooth all th' wrinkles.

Lots of Drupal modules just

Lots o' Drupal modules just have a dev release. We dern't have finals fer views, date, ctools, an' ye name it.

Most folks ha'nae even done their first Drupal 7 site!

We're certainly not ready fer Drupal 8 before 2012.

HTML5 is ok NOW

I get th' feelin' ye're still not gettin' HTML5, even though ye say D8 should use it, I'll warrant ye. Aye thar be certain features that won't work in older browsers (new form controls come t' mind) but t' a large extent HTML5 simply codifies th' way th' browsers work NOW - an' that includes IE7.

There is Zero doubt that Drupal 8 needs t' be HTML5.

CSS3 is a different matter, but one that can largely be left t' individual themes. I dern't see any great need fer CSS3 in core, even in D8.

I totally agree. There is

I totally agree, I'll warrant ye. There is definitely no doubt t' fully support HTML5. HTML5 is designed fer now an' supports graceful degradation so even th' form aren't a problem. The browser's which dern't know th' input type "date" won't provide a special control an' just interpret it as a input field with type "text". Full HTML5 support is crucial if Drupal 8 wan't t' be th' leadin' mobile plattform!

HTML5, Jquery, Node.JS

With th' prevalence o' mobile web HTML5 should be thoroughly included in core. I think Drupal also should leverage PHP 5.3 as a sys requirement, but t' me this isn't as important as th' HTML5 inclusion. Oho! Oho! I like t' see Drupal headin' th' pack, it is interestin' t' me t' see WP adopt taxonomies an' 'views' like features; as th' web gets more complex Drupal really shines b/c it is such a more flexible an' extensible platform.
In this vein I applaud th' efforts o' th' author here -->hey let's work t' integrate an' mutually guide with other projects that be extremely important --JQuery bein' one, an' node.JS bein' another, All Hands Hoay, ye scurvey dog! Supportin' an' urgin' major hostin' companies t' update t' PHP 5.3 is another effort in this vein.

With regards to HTML5, I

With regards t' HTML5, I would much prefer we focus on makin' it a lot easier t' push out whatever markup we want rather than myopically focusin' on one specification. Also we need t' build new theme functions t' get th' remainin' hard coded markup out o' core. I have coined this "agnostic output" meanin' it should be very easy fer th' themer t' push out whatever they want, not what core assumes I want.

Core can make "good assumptions" an' they should be conservative, however it has t' be very easy fer me t' use an HTML5 theme an' have have full control o'er all output. Right now this is not possible in D7 - that is where we need t' place heavy focus, an' worry about core markup after this is possible.

With regards t' some o' th' comments mentionin' mobile - we need t' drop this myth that HTML5 is automagically great fer mobile an' what we really need t' focus on is th' possibility o' havin' capability detection in core. How we do that an' what issues that is goin' t' raise is a discussion that needs t' happen, an' needs t' start very soon.

So rather than simply sayin' we need t' adopt HTML5 thar be thin's that need t' happen first:

1. Make Drupal markup agnostic an' focus on makin' it much easier t' output whatever markup ye want.
2. Decide if we want capability detection in core an' if so, how.

Then we can worry about what HTML5 markup is appropriate fer core. My general thinkin' is not much - keep it conservative an' leave th' full blown HTML5 efforts fer contrib. Our new D8 theme could be HTML5, as could Bartik, but as fer core, I'm thinkin' at th' moment conservative may well be th' better approach - because th' one thin' we do know, an' can know, is that ALL devices support XHTML.

There is a another very good reason fer bein' conservative with HTML5 in core - structural assumptions. A very simple example o' this is th' long standin' debate about what a block is - is it a section, is it nav, is it aside content, yo ho, ho What is a region - aside, section or a generic container (div), All Hands Hoay, Dance the Hempen Jig You see th' more specific ye get structurally (more specific semantics) th' more assumptions we need t' make. To me this is counter t' Drupal's generic nature an' we be once again fallin' into th' "use case myth" (tryin' t' build a product into a framework), whereas Drupal theme layer should not be a product, but a framework. Bartik is th' product, core is th' framework - th' framework needs t' be very generic t' support any use case, not some ideal notion o' what we think that might be.

With regards t' some o' th' other API's, personally I would like t' see push on Geolocation gettin' some support in core an' an assessment o' th' other API's that may be appropriate.

agree - make html must easier to customise (and remove CSS)

Just want t' agree with Jeff here. As someone who has had t' customise th' html o' an entire site recently (t' meet a premade HTML/CSS bounty) I think Drupal should try an' make html output much easier t' completely change/remove.

Also, re CSS(3), dern't have any core stylin' at all, avast! Radical I know (though I am certainly not th' first t' say it by any means) but why not?

Core themes can provide CSS markup, but thar shouldn't be any in modules.

Impossible

Try th' Stark theme in D7, which is about as minimalist as 'tis possible t' get.

Havin' no module CSS at all is impossible. Modules that provide Javascript frequently need CSS t' latch on t', by Blackbeard's sword. Modules also need t' work out o' th' box. If a module provides some output, it needs t' be usable before someone themes it, with a chest full of booty. If it doesn't, then ye're sayin' no one is allowed t' install or use a module who isn't a professional themer. That's an obvi'us dead end. :-)

(And I know ye were talkin' about core, but core is mostly a collection o' modules.)

You're right, but I

You're right, but I definitely think we could make CSS more optional as it were. Maybe we could move t' this kind o' approach (th' approach o' Views 3):

http://jessebeach.drupalgardens.com/content/how-we-architected-css-views-d7

Basically, we need t' make sure sites only have t' use th' CSS th' need t', an' CSS is separated into separate files by clear purpose so that designers can simply unset all th' sheets they dern't need.

I also do think we could remove all CSS from core an' put it into th' core themes, by Blackbeard's sword. People who be writin' their own themes can simply copy an' paste if they be desperate t' not write their own code. You're right this would likely not be possible with all modules however.

Like others have pointed to,

Like others have pointed t', some thin's like HTML5, possibly 5.3 too, may be worth holdin' th' release up fer. jQuery versions tend t' contain API additions an' come out at a much faster rate than Drupal major versions do, so thar is more chance fer flexibility thar I think (unless it were bein' goin' t' be a 12 month release cycle but thar's no chance o' that).

So if we want PHP 5.3, we can decide t' require it now, then make th' decision about release date based on a projection o' uptake, it doesn't have t' be th' other way 'round.

True

That's very true. And if we announce an' discuss that decision properly, then we can, I believe, help brin' more widespread PHP 5.3 adoption sooner, just like we did with GoPHP5.

I think I agree here with

I think I agree here with catch an' jeff. Hosts be already startin' t' move t' 5.3 (Pair is upgradin' everyone this week, an' while they be usually ahead o' th' curve on this stuff, th' rest can't be THAT far behind.) What we likely dern't want is t' get stuck on a laggin' version o' PHP fer th' next 4-5 years. The sharks will eat well tonight! We want t' take advantage o' all th' goodness we can, an' we have demonstrated that we can move thin's forward before, Get out of me rum, All Hands Hoay! I'm in favor o' settin' PHP 5.3. I'm not familiar enough with th' other systems t' comment on them specifically, but I think in general I am in favor o' leanin' more towards th' cuttin' edge than away from it. The drop is always movin', let th' world catch up.

Better yet, implement

Better yet, implement Drupal.behaviors as a jquery plugin separate from jquery core, Get out of me rum, and a bucket o' chum! You dont' have t' argue with jquery devs about why it should be included, plus ye can update an' upgrade it separate from jquery core.

I think D8 should require PHP5.3, simply because 5.3 is so much better, not just fer th' improvements t' th' language but also performance wise compared t' 5.2, I'll warrant ye. Anyone who can't find a host with 5.3 installed could stick with D7.

That's another good point.

That's another good point. Prepare to be boarded! After release, thar is at least a six month period where only new sites get built, an' very sites be migratin' betwixt th' major versions, Ya horn swogglin' scurvy cur! This were bein' especially true fer D6, an' fer D7 it looks no different if http://drupal.org/project/usage/drupal is anythin' t' go by.

So fer widespread PHP 5.3 ability, 'tis less th' release date, an' more 3-6 months afterwards where that will really start t' matter, Avast me hearties, Dance the Hempen Jig My main concern with PHP 5.3 is that it is still hard t' run Drupal 6 contrib modules on it sometimes. The sharks will eat well tonight! So if ye have some overlap betwixt a Drupal 6 site an' a Drupal 8 site, ye're in a bit o' a bind - but those issues may get fixed before D8 is released too.

jQuery devs

The advantage o' workin' directly with th' jQuery core team on their terms is that we get feedback from JS devs that be far smarter than we be, ya bilge rat! Load the cannons! It also means that, goin' forward, th' entire jQuery community can help support an' evolve that framework.

Look at farbtastic, th' jQuery plugin written by Steven Wittens fer Drupal 5's color module. It were bein' a stan' alone jQuery plugin.., Dance the Hempen Jig that no one else used an' it went stale an' snuffed it, and a bottle of rum! We dern't want that t' happen.

Certainly that would be dependent on th' jQuery devs bein' open t' what we're tryin' t' do, but we won't know until we try. And even then, we want -- no, desperately need -- th' input an' feedback from Javascript experts, which by an' large Drupalers be not.

Good points but getting good

Good points but gettin' good JS feedback doesn't require gettin' it into jQuery core, especially if its somethin' very Drupal specific. jQuery core already has somethin' very similar, but not identical, t' behaviors - http://api.jquery.com/live/ Maybe th' Drupal community doesn't need t' reinvent that wheel?

If no one used farbtastic, shouldn't it have gone stale an' snuffed it? Not sure how this applies here.

Could be

My understandin' is that thar be performance issues thar, but I dern't recall th' details. But yes, if we can junk our own home-grown API in favor o' one that's already in jQuery core, we should do so. There be a couple o' issues already open t' do that, linked in th' article above. If live() can in fact replace behaviors, please file an issue an' let's do that, avast. :-)

AFAIC

As far as I'm concerned, th' release schedule is too fast, an' th' Drupal7 module offerin's be a testament. Fire the cannons! Walk the plank! Rapid release cycles be great fer stayin' with th' "edge" o' th' industry, but when each release breaks an entire library o' modules, its hard t' justify movin' t' a new version. The unfortunate part is that th' API really doesn't change "that much" an' a lot o' modules just need a little bit o' love t' be made D7 ready. Rapid release cycles might spell out doom fer a project like this if more effort is not put towards backwards compatibility.

We can't possibly all be expected t' rewrite all o' th' modules every year. Walk the plank! That is insane. Support fer legacy modules would be a huge boon fer scallywags considerin' usin' drupal as a platform.

But o' course, I'm just a developer that doesn't have high profile clients, so what would I know?

Sproutcore

Still thinkin' on this, but I've heard lots o' talk about adoptin' a more MVC approach fer Drupal in general, so that th' renderin' would be totally abstracted from th' business logic (not just different templatin' engines, but almost like Services module fer th' UI itself, if I understood correctly). The sharks will eat well tonight, Hornswaggle Anyhow, went t' a talk on usin' SproutCore front-end with Django back-end, an' it got me thinkin' that this framework fer handlin' th' Drupal UI (It's amazin' with AJAX apparently).

Any proper abstraction layer needs at least 2 implementations t' be legit, an' I'd love t' see SproutCore as th' second UI abstraction (aside from Drupal UI proper), ye scurvey dog. Sproutcore has been used t' create iPad apps an' looks t' be an up-an'-comer fer mobile interface handlin' as well, so it would cover lots o' ground. Also, they've adopted jquery fer their front-end. Oh, an' Yehuda Katz, a core jQuery dev an' th' lubber who wrote "jQuery in Action", started Strobe Inc. with th' other main SproutCore devs, an' they've been really pushin' th' framework in some cool directions.

Can't claim t' know a whole lot about SproutCore right now (as I've only been lookin' into it o'er th' past week), but 'tis gotten me excited so far :)

Hmmm...

Hmmm... relevant:
http://news.ycombinator.com/item?id=2119704

I know that their documentation has gotten way better in th' past few months, an' that they'd ditched their lightweight jquery-like framework in favour o' jquery.., Hornswaggle so I'm not sure how much those valid criticisms still stan'...

Had a quick exchange with Tom

Had a quick exchange with Tom Dale in IRC, an' he were bein' really supportive o' offered advice if we have specific questions:

[4:14PM] I'm actually not familiar with drupal *at all*
[4:15PM] tomdale: but if thar is anythin' I can do t' help with compatibility/integration I'd be happy t'
[4:16PM] tomdale: th' notion behind a SproutCore app is that 'tis 100% client side
[4:16PM] tomdale: yer server doesn't generate any HTML _at all_
[4:16PM] tomdale: 'tis just a first-class consumer o' a JSON or XML feed
[4:16PM] tomdale: IOW, ye pretend yer web client is like an iOS app
[4:17PM] tomdale: or anythin' else that doesn't natively understan' HTML
[4:17PM] tomdale: ye just expose a RESTful backend

WSCCI

Ahso. In that case, SproutCore isn't an alternate front end fer Drupal per se, but somethin' we want t' keep in mind when turnin' Drupal into a RESTful server. That's what th' Web Services core initiative is workin' on (among other related thin's):

http://groups.drupal.org/wscci

This thread in particular is especially relevant:

http://groups.drupal.org/node/148149

If ye or he want t' jump in, that would be great.

Release Cycle

I'm all fer a long release cycle. It is what gave D6 so much momentum an' traction; we have a huge library o' modules an' themes fer it. Load the cannons, I'll warrant ye! If we chase a new Core version every year, that creates too much overhead fer devs out thar. I think 2.5+ years is a good target fer core, which puts us close t' th' end o' 2012.

I'm sorry, but i can't agree

I'm sorry, but i can't agree on that. 2.5 years + fer one major version step, Avast me hearties! Thats t' long, by Blackbeard's sword. We should aim fer a 12-14 month cycle.

Even Dries commented on that issue http://buytaert.net/drupal-7-development-process-retrospective an' more in detail http://buytaert.net/8-steps-for-drupal-8 ( see step 8 ).

There is a sentiment amongst developers that th' Drupal 7 core release cycles were bein' too long. It can make it frustratin' t' contribute t' Drupal core development. And swab the deck! Ye'll be sleepin' with the fishes! Who wants t' work on a feature that might not be used in production fer another 18 t' 24 months? Aarrr! Near th' end o' th' code freeze, thin's heat up, an' scallywags submit a lot more patches. In other words, shorter release cycles could make it more compellin' t' contribute.

I think a shorter release

I think a shorter release cycle fer core is better than a longer one. However, th' reality is that th' contributed modules be goin' t' dictate which version o' Drupal scallywags deploy in th' short term. A lot o' modules still dern't have D7 versions, which is goin' t' impede its adoption.

Hopefully th' community can port more o' them soon, particularly if agencies an' consultancies that need them can sponsor ports.

Hosts ahead of Drupal devs when it comes to 5.3

Just a sidenote about Drupal 6 an' PHP 5.3: My experience were bein' that users an' even shared hostin' were bein' ahead o' core an' contrib developers when it came t' 5.3, an' that a lot o' shared hostin' companies has already switched.

When users started raisin' concerns about all th' errors with 5.3 (not even core supported 5.3 until 6.14) th' first reactions from developers were "dern't use it, Drupal doesn't support it" instead o' "let's make sure D6 an' contribs is error free on 5.3". Core support fer 5.3 came relatively fast, but in contrib it were bein' a mess, an' a lot o' maintainers wouldn't release new releases even though shared hostin' started t' switch t' 5.3 an' th' fixes were known.