D7 Status

From: Angela Byron 

Drupal 7 first opened for development back in February 2008. At DrupalconBoston a month later, we brainstormed on how to tackle some of Drupal's toughest challenges: our usability was not up to par, we were burning time fixing the same bugs over and over, our database abstraction layer suffered many limitations, upgrades were a nightmare, and critical modules such as CCKnot being ported were harming our adoption rates of Drupal 6. Drupal 7 has made tremendous strides since then to solve each of these problems, as well as many others. Among the improvements are a revamped UI, a testing framework, a new database abstraction layer, a browser-based upgrade system for contributed modules and themes, and CCK in core.

Now it's time to head into the final stretch: stomping down the list of critical bugs, so that we can release Drupal 7.0 out into the world! :D

To help this along, Dries and I will create the first alpha release of Drupal 7 on January 15, 2010, Drupal's ninth birthday. For developers working on Drupal7 clean-ups, particularly around anything that is touching APIs or the UI in a fundamental way, your changes will need to be completed by then. Once the alpha is released, we will start to treat Drupal 7 as an actual stable release, which means nothing but non-API-breaking bug fixes.

The initial brainstorming at Drupalcon just a few weeks after development opened for Drupal 7 was instrumental in laying astrong foundation for the entire release, I would love to see Drupal 8 get the same opportunity. However, this means releasing Drupal 7 before Drupalcon SF (mid-April), so that our attention is not divided between getting our past efforts out into the world, and deciding what our future efforts will be.

And when does Drupal 7 come out? When the list of critical issues [1] hits zero (currently at 340, though this will fluctuate all over the place for awhile as non-critical issues are marked such as and new critical issues are found). To spook you with a little math, if we want to see a Drupal 7.0 release by the end of March, at the current total we need to solve roughly 120 issues per month,or 30 issues per week, or 5 per day. Yipes! :)

Obviously, the more people we have helping out with fixing critical issues, the faster this number will go down. So if you haven't yet played around with Drupal 7, now's a great time to start! Pick a critical bug that looks interesting/achievable, and take the opportunity to learn a bit about the changes in Drupal 7 at the same time while you solve it. There are always folks in #drupal and #drupal-contribute on irc.freenode.net to help you, and there are a variety of bugs for all skill levels and areas of expertise.

Let's rock!

[1] http://drupal.org/project/issues/search/drupal?...


Comment: Please be relevant, civil, non-commercial.

Semantic web and Drupal video

Ubercart 3

On 3-Jan-10, at 4:47 PM,

On 3-Jan-10, at 4:47 PM, Susan Stewart wrote:

Someone suggests this every time a new version of Drupal comes out -- always someone who, like yourself, is not a programmer and has no idea what such a thing entails.  Get to know Drupal and its code a little better, and read http://drupal.org/node/65922 which explains why we don't cripple Drupal in the name of backwards compatibility, or worse, create some sort of kludgy compatibility layer to hold it down.

If a module has sufficient interest, it will be upgraded quickly to the next version of Drupal.  Anyone can do it with an investment of time and programming skills, or of dollars.  You can visithttp://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx to see a list of contrib modules that have promised to have a D7 compatible release on the day D7 is released.

I know that for non-programmers and those not familiar with Drupal, this all seems strange, but that first link I gave you is a great explanation of why it is part of the core Drupal philosophy.

Susan gave good resources here.
I think it's a good goal to want to make 6 => 7 transitions easier on people. I think backwards-compatibility layers though are the wrong way to do it, not to mention impossible in most cases.
The /right/ way to do it is to work on tools that make porting code between versions a much easier process. These tools are all consolidated in the Coder module: http://drupal.org/project/coder. There's a video at http://www.lullabot.com/videocast/porting-drupal-modules which shows converting a 5.x module to 6.x in about 15 minutes using Coder module and some basic copy/paste/modify PHP skills. Coder module works by having rules defined for each API change and raising warnings when it encounters old code. The 7.x version of Coder even comes with a new Coder Upgrade module (called Deadwood in 6.x), which will attempt to make the changes for you.
Anyone who has the itch of making the 6.x => 7.x transition smoother should be hunkering down in the Coder module queue to write up some of the changes at http://drupal.org/update/modules/6/7 into rules that can then be applied en masse by everyone. Even if you don't consider yourself a "real" programmer, but you know enough to be dangerous, you could help with this task. It's a great way to get familiar with the changes you'll need to know in a few months, well ahead of time, and it helps make the transition to the new version easier for everyone.