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.
For example...
HTML5
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.
PHP 5.3
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.
jQuery
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.
Drupal has a lot of custom Javascript, much of it written before jQuery implemented certain features. Of course, jQuery now implements many of those and there's a push to drop our custom implementations in favor of what jQuery and others have implemented in the meantime. That's all well and good, but wouldn't it be better to not have to write our own versions in the first place?
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 Drupal.behaviors into jQuery itself. Get it reviewed by Javascript experts who are five times as skilled as any of we Drupalers are, get it good, and get it into jQuery itself. Then we can leverage it in Drupal with less custom code for us to maintain, plus we get the good karma of working directly with fellow open source projects. Everybody wins.
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.
It's all about planning
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?
HTML 5 and Javascript
If we want Drupal 8 to be a major platform for mobile web development, integrating HTML 5 and reworking our JavaScript is an evidence. Let's remember that IE doesn't really exist in a world of Webkit mobile browsers (iPhone/Android/iPad). With the core context initiative you're taking part in, it will even enable Drupal to 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 of D8 within 12 months. With all the cool new Drupal 8 initiatives, D8 will be a major release. As with D7 it will take time to smooth all the wrinkles.
Lots of Drupal modules just
Lots of Drupal modules just have a dev release. We don't have finals for views, date, ctools, and you name it.
Most folks haven't even done their first Drupal 7 site!
We're certainly not ready for Drupal 8 before 2012.
HTML5 is ok NOW
I get the feeling you're still not getting HTML5, even though you say D8 should use it. Yes there are certain features that won't work in older browsers (new form controls come to mind) but to a large extent HTML5 simply codifies the way the browsers work NOW - and that includes IE7.
There is Zero doubt that Drupal 8 needs to be HTML5.
CSS3 is a different matter, but one that can largely be left to individual themes. I don't see any great need for CSS3 in core, even in D8.
I totally agree. There is
I totally agree. There is definitely no doubt to fully support HTML5. HTML5 is designed for now and supports graceful degradation so even the form aren't a problem. The browser's which don't know the input type "date" won't provide a special control and just interpret it as a input field with type "text". Full HTML5 support is crucial if Drupal 8 wan't to be the leading mobile plattform!
HTML5, Jquery, Node.JS
With the prevalence of mobile web HTML5 should be thoroughly included in core. I think Drupal also should leverage PHP 5.3 as a sys requirement, but to me this isn't as important as the HTML5 inclusion. I like to see Drupal heading the pack, it is interesting to me to see WP adopt taxonomies and 'views' like features; as the web gets more complex Drupal really shines b/c it is such a more flexible and extensible platform.
In this vein I applaud the efforts of the author here -->hey let's work to integrate and mutually guide with other projects that are extremely important --JQuery being one, and node.JS being another. Supporting and urging major hosting companies to update to PHP 5.3 is another effort in this vein.
With regards to HTML5, I
With regards to HTML5, I would much prefer we focus on making it a lot easier to push out whatever markup we want rather than myopically focusing on one specification. Also we need to build new theme functions to get the remaining hard coded markup out of core. I have coined this "agnostic output" meaning it should be very easy for the themer to push out whatever they want, not what core assumes I want.
Core can make "good assumptions" and they should be conservative, however it has to be very easy for me to use an HTML5 theme and have have full control over all output. Right now this is not possible in D7 - that is where we need to place heavy focus, and worry about core markup after this is possible.
With regards to some of the comments mentioning mobile - we need to drop this myth that HTML5 is automagically great for mobile and what we really need to focus on is the possibility of having capability detection in core. How we do that and what issues that is going to raise is a discussion that needs to happen, and needs to start very soon.
So rather than simply saying we need to adopt HTML5 there are things that need to happen first:
1. Make Drupal markup agnostic and focus on making it much easier to output whatever markup you want.
2. Decide if we want capability detection in core and if so, how.
Then we can worry about what HTML5 markup is appropriate for core. My general thinking is not much - keep it conservative and leave the full blown HTML5 efforts for contrib. Our new D8 theme could be HTML5, as could Bartik, but as for core, I'm thinking at the moment conservative may well be the better approach - because the one thing we do know, and can know, is that ALL devices support XHTML.
There is a another very good reason for being conservative with HTML5 in core - structural assumptions. A very simple example of this is the long standing debate about what a block is - is it a section, is it nav, is it aside content? What is a region - aside, section or a generic container (div). You see the more specific you get structurally (more specific semantics) the more assumptions we need to make. To me this is counter to Drupal's generic nature and we are once again falling into the "use case myth" (trying to build a product into a framework), whereas Drupal theme layer should not be a product, but a framework. Bartik is the product, core is the framework - the framework needs to be very generic to support any use case, not some ideal notion of what we think that might be.
With regards to some of the other API's, personally I would like to see push on Geolocation getting some support in core and an assessment of the other API's that may be appropriate.
agree - make html must easier to customise (and remove CSS)
Just want to agree with Jeff here. As someone who has had to customise the html of an entire site recently (to meet a premade HTML/CSS design) I think Drupal should try and make html output much easier to completely change/remove.
Also, re CSS(3), don't have any core styling at all! Radical I know (though I am certainly not the first to say it by any means) but why not?
Core themes can provide CSS markup, but there shouldn't be any in modules.
Impossible
Try the Stark theme in D7, which is about as minimalist as it's possible to get.
Having no module CSS at all is impossible. Modules that provide Javascript frequently need CSS to latch on to. Modules also need to work out of the box. If a module provides some output, it needs to be usable before someone themes it. If it doesn't, then you're saying no one is allowed to install or use a module who isn't a professional themer. That's an obvious dead end. :-)
(And I know you were talking about core, but core is mostly a collection of 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 to this kind of approach (the approach of Views 3):
http://jessebeach.drupalgardens.com/content/how-we-architected-css-view…
Basically, we need to make sure sites only have to use the CSS the need to, and CSS is separated into separate files by clear purpose so that designers can simply unset all the sheets they don't need.
I also do think we could remove all CSS from core and put it into the core themes. People who are writing their own themes can simply copy and paste if they are desperate to not write their own code. You're right this would probably not be possible with all modules however.
Like others have pointed to,
Like others have pointed to, some things like HTML5, possibly 5.3 too, may be worth holding the release up for. jQuery versions tend to contain API additions and come out at a much faster rate than Drupal major versions do, so there is more chance for flexibility there I think (unless it was going to be a 12 month release cycle but there's no chance of that).
So if we want PHP 5.3, we can decide to require it now, then make the decision about release date based on a projection of uptake, it doesn't have to be the other way 'round.
True
That's very true. And if we announce and discuss that decision properly, then we can, I believe, help bring 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 and jeff. Hosts are already starting to move to 5.3 (Pair is upgrading everyone this week, and while they are usually ahead of the curve on this stuff, the rest can't be THAT far behind.) What we probably don't want is to get stuck on a lagging version of PHP for the next 4-5 years. We want to take advantage of all the goodness we can, and we have demonstrated that we can move things forward before. I'm in favor of setting PHP 5.3. I'm not familiar enough with the other systems to comment on them specifically, but I think in general I am in favor of leaning more towards the cutting edge than away from it. The drop is always moving, let the world catch up.
Better yet, implement
Better yet, implement Drupal.behaviors as a jquery plugin separate from jquery core. You dont' have to argue with jquery devs about why it should be included, plus you can update and upgrade it separate from jquery core.
I think D8 should require PHP5.3, simply because 5.3 is so much better, not just for the improvements to the language but also performance wise compared to 5.2. 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. After release, there is at least a six month period where only new sites get built, and very sites are migrating between the major versions. This was especially true for D6, and for D7 it looks no different if http://drupal.org/project/usage/drupal is anything to go by.
So for widespread PHP 5.3 ability, it's less the release date, and more 3-6 months afterwards where that will really start to matter. My main concern with PHP 5.3 is that it is still hard to run Drupal 6 contrib modules on it sometimes. So if you have some overlap between a Drupal 6 site and a Drupal 8 site, you're in a bit of a bind - but those issues may get fixed before D8 is released too.
jQuery devs
The advantage of working directly with the jQuery core team on their terms is that we get feedback from JS devs that are far smarter than we are. It also means that, going forward, the entire jQuery community can help support and evolve that framework.
Look at farbtastic, the jQuery plugin written by Steven Wittens for Drupal 5's color module. It was a stand alone jQuery plugin... that no one else used and it went stale and died. We do not want that to happen.
Certainly that would be dependent on the jQuery devs being open to what we're trying to do, but we won't know until we try. And even then, we want -- no, desperately need -- the input and feedback from Javascript experts, which by and large Drupalers are not.
Good points but getting good
Good points but getting good JS feedback doesn't require getting it into jQuery core, especially if its something very Drupal specific. jQuery core already has something very similar, but not identical, to behaviors - http://api.jquery.com/live/ Maybe the Drupal community doesn't need to reinvent that wheel?
If no one used farbtastic, shouldn't it have gone stale and died? Not sure how this applies here.
Could be
My understanding is that there are performance issues there, but I don't recall the details. But yes, if we can junk our own home-grown API in favor of one that's already in jQuery core, we should do so. There are a couple of issues already open to do that, linked in the article above. If live() can in fact replace behaviors, please file an issue and let's do that. :-)
AFAIC
As far as I'm concerned, the release schedule is too fast, and the Drupal7 module offerings are a testament. Rapid release cycles are great for staying with the "edge" of the industry, but when each release breaks an entire library of modules, its hard to justify moving to a new version. The unfortunate part is that the API really doesn't change "that much" and a lot of modules just need a little bit of love to be made D7 ready. Rapid release cycles might spell out doom for a project like this if more effort is not put towards backwards compatibility.
We can't possibly all be expected to rewrite all of the modules every year. That is insane. Support for legacy modules would be a huge boon for people considering using drupal as a platform.
But of course, I'm just a developer that doesn't have high profile clients, so what would I know?
Sproutcore
Still thinking on this, but I've heard lots of talk about adopting a more MVC approach for Drupal in general, so that the rendering would be totally abstracted from the business logic (not just different templating engines, but almost like Services module for the UI itself, if I understood correctly). Anyhow, went to a talk on using SproutCore front-end with Django back-end, and it got me thinking that this framework for handling the Drupal UI (It's amazing with AJAX apparently).
Any proper abstraction layer needs at least 2 implementations to be legit, and I'd love to see SproutCore as the second UI abstraction (aside from Drupal UI proper). Sproutcore has been used to create iPad apps and looks to be an up-and-comer for mobile interface handling as well, so it would cover lots of ground. Also, they've adopted jquery for their front-end. Oh, and Yehuda Katz, a core jQuery dev and the dude who wrote "jQuery in Action", started Strobe Inc. with the other main SproutCore devs, and they've been really pushing the framework in some cool directions.
Can't claim to know a whole lot about SproutCore right now (as I've only been looking into it over the past week), but it's 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 the past few months, and that they'd ditched their lightweight jquery-like framework in favour of jquery... so I'm not sure how much those valid criticisms still stand...
Had a quick exchange with Tom
Had a quick exchange with Tom Dale in IRC, and he was really supportive of offered advice if we have specific questions:
WSCCI
Ahso. In that case, SproutCore isn't an alternate front end for Drupal per se, but something we want to keep in mind when turning Drupal into a RESTful server. That's what the Web Services core initiative is working on (among other related things):
http://groups.drupal.org/wscci
This thread in particular is especially relevant:
http://groups.drupal.org/node/148149
If you or he want to jump in, that would be great.
Release Cycle
I'm all for a long release cycle. It is what gave D6 so much momentum and traction; we have a huge library of modules and themes for it. If we chase a new Core version every year, that creates too much overhead for devs out there. I think 2.5+ years is a good target for core, which puts us close to the end of 2012.
I'm sorry, but i can't agree
I'm sorry, but i can't agree on that. 2.5 years + for one major version step? Thats to long. We should aim for a 12-14 month cycle.
Even Dries commented on that issue http://buytaert.net/drupal-7-development-process-retrospective and more in detail http://buytaert.net/8-steps-for-drupal-8 ( see step 8 ).
I think a shorter release
I think a shorter release cycle for core is better than a longer one. However, the reality is that the contributed modules are going to dictate which version of Drupal people deploy in the short term. A lot of modules still don't have D7 versions, which is going to impede its adoption.
Hopefully the community can port more of them soon, particularly if agencies and consultancies that need them can sponsor ports.
Hosts ahead of Drupal devs when it comes to 5.3
Just a sidenote about Drupal 6 and PHP 5.3: My experience was that users and even shared hosting was ahead of core and contrib developers when it came to 5.3, and that a lot of shared hosting companies has already switched.
When users started raising concerns about all the errors with 5.3 (not even core supported 5.3 until 6.14) the first reactions from developers were "don't use it, Drupal doesn't support it" instead of "let's make sure D6 and contribs is error free on 5.3". Core support for 5.3 came relatively fast, but in contrib it was a mess, and a lot of maintainers wouldn't release new releases even though shared hosting started to switch to 5.3 and the fixes were known.