![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
If I would schedule Drupal 8 then I would very quickly look around the issue queue and get a list of desired not-too-big cleanups and fixes that would happen before Chicago. Code slush before the full thaw. (kudos to catch for the idea btw) Then at Chicago at the core conversations we could figure out the big things we want and work on them until and including London. End of London, soft freeze! 2012 North America DrupalCon, release. Nice and tight, about 16 months lots and lots of cleanup, UI love and not much but enough craziness.
Commenting on this Story is closed.
I like this plan a lot.
-moshe
Agreed.
We need a nice & tight schedule, even if that means pushing certain things to Drupal 9 (release early, release often...)
Just imagining Drupal 8 getting released in 2014 makes me want to hide under my bed. It's demotivating.
And cleaning up first what couldn't be done in time for D7 before getting all our crazy-thaw patches in would make much sense.
Alernating one big plan, world-changing, never-seen-before release with a smaller one appears to make sense. +1
A major issue we had between Drupal 6 and 7 was a number of things that went into Drupal 6 that weren't built on (and even abandoned for long periods in some cases) in Drupal 7. Both actions and OpenID fit that description, actions went in just before Drupal 6 code freeze.
While I'm starting to get motivated to work on new things for Drupal 8, I'm also very concerned that things like profile module, the conversion of various things to fields, and the completion of the Entity API (not an exhaustive list) all get in as early as possible in the release cycle, so that there's no risk of releasing D8 with any of these in the same state they are now.
I'd also like to see serious clean up of the module and theme subsystems - we started on this a bit in D7 but some of the underlying code like module_list() is very, very shaky.
Care about websites not only for Drupal marketing.
I'd better to remove bugs from many essential modules not only rushing with new drupal versions.
Many modules (Path redirect,Nodewords...) are in beta or have many bugs. Drupal without them is useless :(
http://googlewebmastercentral.blogspot.com/2009/09/google-does-not-use-keywords-meta-tag.html
Meta keywords are only one facet of the nodewords module. Meta description is still valid
There is not a single team of people working on core and contrib modules, there are instead a tonne of individuals who work either on core, or certain contrib modules or both. So listing random contrib modules that you happen to use and holding them up as a reason for people not work on core misses the point entirely.
Great idea. But would be necessary that upgrading from 7 to 8 could be done with a minimal effort.
In general it's easier for contrib modules if you release often.
You have less changes and especially the api isn't changed too long.
Support. Who cares about it?
Drupal 6 will be a 4-5 y.o. system in 2012, why should we support such an old system?
Developers have 1.5 years to port their modules to D7 - if they didn't start it 1 year ago.
Great information you got here. I've been reading about this topic for one week now for my papers in school and thank God I found it here in your blog. I had a great time reading this Adidas Adizeros
Slush Maker
Really nice post.. very helpfull for us....really i got very usefull information from here. and i was searching about towing services but i got that i read it Adidas Adizero
I really like this infomartion; it's truly first-class to read this. I wait for you will share news like this repeatedly, download free full version counter strike 1.6, spiderman 3 pc download, pc need for speed most wanted