So here we are. The feature-set and API of Drupal 7 is about to freeze. It contains many - actually plenty - of awesome and noteworthy improvements and new features. But those will be covered elsewhere and I don't want to talk about that.

Instead, we should talk about how we can assure a top quality and deliver a new Drupal release that actually works and is usable, both for users and developers. By all means, I have no influence on the decisions that will be taken, so this is a plain recommendation from someone who develops both for Drupal core and contributed modules, and simply wants to help people to build great Drupal sites.

The problem

Initially, the release of Drupal 6 primarily failed for a very simple reason: Drupal 6 contained a lot of new features and API functionality. But most of them are only implemented partially. To name a few examples: You can translate content, but you cannot translate menus, taxonomy terms, configuration settings (like the site's name), data of contributed modules, or anything else. All Drupal modules can expose triggers (system events) that should allow the site administrator to assign actions to perform when a certain event happens, but since even Drupal core modules do not fully implement triggers/actions, the entire feature was not really adopted by contributed modules - therefore, the entire concept of triggers/actions is widely unknown among Drupal developers, which also explains why that API had nearly zero improvements during the Drupal 7 cycle.

We should not do the same mistake again. Whereas the mistake is to introduce new, half-baked features that are "only available" or inconsistently applied. For a long time, I'm arguing for changing our date-based code freeze into a date-based feature freeze. Which simply means the same. But automatically opens up exceptions for API changes belonging to an already introduced new feature past code freeze. It simply makes no sense at all to release a new feature or API change that only works here or there, or which is not applied consistently. That's like: "Hey, we have ice-cream now!" -- "Great! Uhm, but no cups?!"

Details

After discussing this very annoying fact with Stefan all over again in the past two years, he recently came to the conclusion that - if Drupal would use a DVCS supporing better merge functionality than CVS, we could do separate short-term and long-term feature branches - not holding up smaller improvements by larger improvements. However, since we cannot investigate such options yet, my recommendation still is to immediately introduce a feature-freeze for Drupal 7.

So far, Angela Byron was the only one who strongly disagreed to a feature-freeze, because she fears that Drupal core developers would be annoyed by the fact that they cannot use their contributions to the new Drupal release earlier. I disagree with that reasoning. Instead, a feature-freeze would allow all Drupal developers to focus on the newly introduced features, understanding them better and makíng them better/work/usable in the additional "feature completion" time-frame. A great chance for many Drupal core, but also contributed module developers to improve their skills and understanding of new core features - which, as a matter of fact, is one of the top problems with regard to Drupal core development.

As of now, DBTNG (the new database abstraction layer introduced in Drupal 7) seems to be the only new feature that has been implemented (almost) properly.

Feature completion

Most probably, this list is a bit biased, but as far as I can see, the mission critical exceptions for a Drupal 7 "code-freeze" to complete the introduced features are:

DBTNG
DIE update_sql() DIE!
Remove the legacy database layer functions.
Field API
Impossible to join or order by on field tables without using Views
Make custom blocks fieldable
'as link' formatters need a generic way to build the url of an 'entity'

...and other, remaining issues tagged with Fields in Core.

Internationalization
TF #1: Allow different interface language for the same path
TF #2: Convert node title to fields
TF #3: Translatable fields UI
Distinguish between UI language and content language
Localize date formats
Add msgctxt-type context to t()
Write locales data API
Minimum support for multilingual variables

...and further remaining issues tagged with i18n sprint.

Also note that translatable fields introduced an entirely new concept to translate content in core. What has been introduced as of now, is NOT ready for mass-consumption yet, and especially handling entities with translatable fields in Views would be a total nightmare right now.

Token / RDF
Move user_mail_tokens() and emails to token system
UI for tokens
Centralize entity properties meta data
Sending mail and displaying a message in a trigger doesn't honor tokens
AJAX
move AHAH-'add more' to the new generic AHAH callback
AJAX/AHAH 'callback' support only works for 'submit' and 'button' elements - Should work for all triggering elements
Standardize the return of status messages in AJAX callbacks
AJAX pager
Remove drupal_goto() calls from form validate and submit handlers - they break AHAH/AJAX
RDF
RDFa: Add semantics from the ground up
core RDF module
Add RDF to the field module
Add RDF to the node module
Add RDF to the user module
Triggers/Actions
trigger.module and includes/actions.inc need overhaul
Add comment notifications via e-mail
Filter system
Last-minute UX: Revamp text format/filter configuration
Allow default text formats per role, and integrate text format permissions

Comments

We've outlined some issues that should be addressed to improve universal access on our blog.

I completely agree, 7.x is the Drupal core we will be using for at least the next 2 years... so let's finish what we have already begun.

Hey Daniel,

Thanks for a frank and well thought out writeup on core development. Its great to get this kind of insight into 'the state of things'.

Cheers!

I think things like fields in core, if not fully implemented, would be bad for the community. Getting 7 right is more then bug fixing, it's making it consistent and not confusing. Out with the old, in with the new!

I'm totally agree with you, partially implementing important features is wasting of time. Core modules should be fully compatible with new features. KDE and many other opensource softwares currently have feature freeze before code freeze. this approach may require more time, but the result is a solid, modern , bug free core.
I think you should openup a group and invite core developers and the other developers to join (specially dries , angie, gabor , etc) you can tell everyone your reasons and finally an online survey will display the will of the community.
It has been done before for drupal release cycle. but things are different now, we have full automated test coverage for core.

PS : Drupal really needs a more modern VCS!

Regards

I agree that D7 does not feel finished yet. Major changes such as fields in core, admin re-organization and RDF are not complete. However, I don't think there is cause for alarm quite yet.

My understanding of the release cycle has always been that all issues marked as critical need to be fixed before a release candidate. Right now, the majority of issues listed here are marked as critical. Hopefully this means that "new features" that are really finishing off what has been started will be accepted after code freeze. What we don't need right now is anyone starting something new. The focus has shifted to getting what we have now right.

I'm sure that Dries and/or Angie will have something to blog about on September 1st. Hopefully they clarify what will and will not be accepted then.

I agree with Rick, a day or two before code freeze is a bit too late for this proposal. I think it would be best to stick with the "release happens when there are 0 critical bugs" especially given that most of these are critical they will still get dealt with before release.

Sounds like a good idea, but just in case it doesn't happen, we could try and do a quicker than usual D8 which works like Apple's Snow Leopard. Just use the D8 upgrade to complete and clean-up all those items that have been only partially implemented. Just a backup idea in case the Feature Freeze one doesn't happen.

About the "Critical Bugs" having to be zero before release. That's true, but I think Daniel is thinking more of items hat are missing not broken. Missing won't be covered by fixing the "Critical Bugs"

why do you say that the D6 release failed? I do not agree. You can translate all of those things, and you can use actions and triggers, there is no real issue with actions (or maybe I just did not find any, but I can tell I am using them, and still improving them)..
and the D6 release is not over, it's just getting better and better every day, see features for example.. Drupal is not just the code from core..

as I see the only way to make Drupal core functionality even better is to use it. Using core functionality inside Drupal core is not a real use case. So D7 release will be better after the release, without changing core, when 5000 modules will be released for D7.. If some API is wrong in D7, then it will be fully explored only after the release, and hopefully fixed in D8..

we can go and improve the API for years, it always could be better, but we need to ship it, to achieve our goals..

I could say I agree, but not being involved with Drupal I don't think saying I agree would mean much, but for an observer on the sidelines, my feeling about D7 code freeze is

"Who really NEEDS it, or can't live without it?"

Lots of sites are still on D5, others have only just begun to move to D6, and are still yet to absorb the new concepts in it.
D7 as it is should be a playground for those who want who want to take time to absorb its new features and give some feedback into their design while they are still doing the paid work in D6 and D5. The new features will be better appreciated and understood when they can be compared with what exists in D5 & D6.

I'm in no rush for drupal 7, and when it comes I'd rather, as you say, that things are consistent. This also makes the system easier to learn.

Exactly, i have 4 websites with Drupal. two of them were long time after Drupal 6 release so i made them with D6 and the others were few month after Drupal 6's release so i built them with D5 because of contributed modules, i don't have any plan to upgrade , i just don't see that much of a difference between D5 and D6 to worth the effort. i still have problem (not the same problems ofcurse ) with images, private public handling , i18n, etc

What i'm trying to say is the different between two releases should be big enough to motivate the developers of this thousands modules to upgrade their modules .

I have at least more than 8 critical contributed modules on each installation and i think the others have even more, IMHO We should admit that the true power of Drupal couldn't be unleashed without contributed modules. after all Drupal is a framework as well.

"So far, Angela Byron was the only one who strongly disagreed to a feature-freeze, because she fears that Drupal core developers would be annoyed by the fact that they cannot use their contributions to the new Drupal release earlier."

Sorry? I don't ever remember saying something like this. Do you have a link?

I have opposed dedicating an entire Drupal release (such as Drupal 8) to clean-up and disallowing new features for fear of losing contributor motivation. But I've obviously no problem feature freezing Drupal 7 on the code freeze date. ;)

I think this sounds like a good idea and seems to be what happens in commercial software. When a major update comes out, the features don't change during its lifecycle but problems are fixed. I'm sure the same thing happens during such software's development cycle.

I'm also in favor of a DVCS. To throw my vote in, I suggest Mercurial. It's nicely cross-platform and easy to install on multiple platforms (Windows, Mac OS X, and Linux). It can even be installed on shared hosting. I know that's likely to be a big debate and at this point, any choice could alienate and aggravate people.

I've been maintaining a Drupal repository in Mercurial since sometime in the Drupal 5 cycle, and have a repo tracking Drupal 6 releases on Bitbucket.org.

This might sound fussy, but for this kind of post the date it was posted is pretty critical to understand when in the development process you're writing about, and the date appears nowhere in the article. People have to look at the comments and make the assumption that the first comment came on the article's date, or at least close.

Shouldn't have to read over the post for context, or look at the comments, to guess when it was made. Shouldn't have to guess at all.

Hey there. I have developed several sites in Drupal 5.
But when I switched to Drupal 6, I found it really slow while writing custom essays.
I guess there won't be any performance issues with Drupal 7 and also will it be PHP5.3 and eventually PHP6 compatible?

A user does not necessarily have to be a geek for using Drupal. All that is required is some basic technical knowledge base such as basic browsing, word processing etc. Nothing like advanced programming or HTML skills are needed to use this award-winning CMS. It comprises of an intuitive-to-use web installer that makes its installation process quite simple. Then, you need to choose your website design and the content types for the same.

Don

The most important thing while designing a site is to make sure that your purpose of site development is solved and is the prime highlight of your website. But this does not mean that your site has to be in columns, you can have an extremely creative site even with Drupal designing, yet get noticed. Here are some important tips that will help you get a creatively upgraded site that too with Drupal designing techniques.

Winston,
utah photography

As mentioned also above, I must thank you for this post. My general impression is that Drupal.org follow strictly unmentioned and unspoken organizational voluntary contribution rules. Therefore I do not wonder anymore if with any new core version Drupal-Users (of what ever lever of implementation) will find bugs due to not complete development, patching and implementation sessions. I allow to cite Dries Buytaert (I hope some of you remember in which occasion and exactly how he expressed and said) "I want to eliminate the Webmaster from Drupal roles". It should be happen around the DC Drupal Convention, I guess. As to specify I'm not a coder but a "User". I fully agree that your proposal would help many Drupal.org voluntary Members and Contributors but only when "Users and Contributors" on Drupal.org have really a democratic and well organized Community they may achieve changes for all related Drupal Management Systems. I am really not convinced that you can "Eliminate" a "Webmaster", not on Drupal and neither on other Content Management Systems. Drupal is Great but much greater are the single individuals, those prominent contributors or simple user (like me or You) that with their feedback did make what Drupal is today.

That is totally fine, I am not yet ready to port my websites into version 7 anyway :) Besides, modules for search engine optimization that I am using might not be compatible with the new version.

Drupal has the ability to eclipse Wordpress in popularity, but the platform people do need to make sure these not-so-little details are properly addressed before it will get the attention it deserves.

- Milt

Does anyone happen to know a few good books on drupal, i have got the gist of it but having some tech issues with understanding some of it.

I have to second that, atleast the next 2 years. i think 7.x is a brilliant peice of kit in your tool belt and it would take alot to beat. chears guys

I cant wait for the next update! I am a huge drupal fan and I think it really will have some improvements from the previous version.

Thanks Gwenn Evans

@ Alex
There are many books on Packt Publishing... their website is also done with Drupal and Ubercart.
About Drupal 7.x we are very close to a beta release!!! Help the community to test the alphas!

We can all predict when Drupal 7 will be released at
http://whenwill.org/drupal_7_be_released

Current predictions has it at October 27

@olof: Actually, we even have an official site for calculating the estimated release date of Drupal 7 based on "live" real world data:

http://drupal7releasedate.com

As it says in step one "separation between framework and product " i think this is where drupal 7 gets unstuck

If to beleive predictions from the upper comments the release should be in a week.
How do you think - is this real?
Regards, Jeremy Right

Lets not waste time - lets just get drupal 7 off the ground before we consider doing other things.
Keep up the good work guys. I love drupal.

Thanks for sharing this link, but argg it seems to be offline... Does anybody have a mirror or another source? Please reply to my message if you do!

I would appreciate if someone here at www.unleashedmind.com could repost it.

Thanks,
Thomas

I just installed the latest version of drupal and it is now stable. The second release seemed to fix most of the bugs.

I think this is probably dated, but even the last update has bugs and is problematic. :)
I hope they fixed the remaining Drupal bugs in the next release.

Wow, 7 had a lot of awesome new features and improvements. It is the core used!

I'm in no rush for drupal 7, and when it comes I'd rather, as you say, that things are consistent. This also makes the system easier to learn.

This is my first time i visit here. I found so many entertaining stuff in your blog, especially its discussion. From the tons of comments on your articles, I guess I am not the only one having all the leisure here! Keep up the good work.

I just installed the latest version of drupal and it is now stable. The second release seemed to fix most of the bugs.
Best regards, Alex

we love drupal, just installed the latest version and it rocks. our customers love it.

We are just about finished with our new site which is Drupal based & I am very excited about how it is coming together. I am looking forward to launching the new site in a few days!

Thanks,
Robert Scott