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.
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?!"
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.
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:
- 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.
- 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
- 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
Remove drupal_goto() calls from form validate and submit handlers - they break AHAH/AJAX
- 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
- 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