You are here
Note: some of the information on this page is out of date. For the latest information about how Drupal releases are managed, see http://drupal.org/core/release-cycle.
In talking to Drupal developers at DrupalCon, it was clear that there are some questions about the Drupal 8 feature freeze and code freeze. Questions like: What can we still work on after feature freeze? When do I start porting my Drupal modules to Drupal 8? When can I start testing Drupal 8? Let's address these questions and more in this blog post.
In addition to that, I am aligning our use of alpha and beta releases more inline with industry standards and changing the date of the code freeze, to leave more room to work on improving coherence. Lastly, I also wanted to document my expectations for contributed module developers/authors -- when they are expected or encouraged to do what.
During development phase (now to December 1)
Here are things we do while we're still in development; we aim to prioritize new features and major API changes.
- New features and major new APIs.
- Initial conversions of major new APIs, to ensure additional features are not needed to support them.
- Refactoring required to unblock additional functionality.
During feature freeze (December 1 to April 1)
The goal of the feature freeze is to improve the implementation of existing features and to improve consistency and coherence of core by removing special cases, and unifying duplicate ways of doing things by converting core to use new APIs, etc.
During this phase we stop adding new subsystems. Refactoring of existing subsystems, smaller API changes and API additions are allowed if they help improve consistency and coherence of the existing functionality or are necessary in order to resolve specific critical tasks and bugs.
For example, the following are still welcome and encouraged during feature freeze:
- Completing conversions of
variable_X()to CMI, and removing the variable system.
- Optimizing and cleaning up bootstrap by refactoring page caching and session handling to use Symfony components.
- Better integrating features added before feature freeze (e.g., integrating an existing Layout UI with existing context-aware Blocks, or Views with EntityFieldQuery).
We will start rolling alpha releases during the feature freeze. Contributed project authors who want to help improve the core APIs to better support their projects, can use these alpha releases to begin porting their modules, themes, and distributions. Core developers seek feedback and suggestions from contributed project authors on how to streamline the core APIs.
During code freeze (April 1 to RC1)
The goal of the code freeze is to fix remaining bugs, and prepare for release. Improving coherence of the code base is no longer the goal. Hence, we discourage refactoring, and shift attention from things that are nice to do to things that we must do.
From the code freeze on, we will roll beta releases. Contributed project authors should use the beta releases to port and improve their projects. We encourage contributed authors to start early in the code freeze, as we can still make API changes, if necessary, to work around problems.
Site builders are encouraged to test new installations of Drupal 8 on their development servers.
From code freeze until RC1, we want to do this:
- Improve the Drupal 7 to Drupal 8 upgrade path
- Performance optimization
- Security hardening
- Minor UI improvements
- String and documentation improvements
- Other tasks that didn't get done by code freeze, but that core committers consider necessary; these will likely be marked as ‘critical tasks'.
Release Candidate to Release
We release a first Release Candidate when nearly all critical bugs and tasks are fixed, and a Drupal 7 to Drupal 8 upgrade path is functional. We aim to do this at least two months (around July, 2013) before the scheduled release date (around September, 2013).
We encourage Drupal 7 site owners to test the upgrade path and test contributed modules on their staging sites. We also encourage all contributed project authors to finalize their ports, with the goal of stable releases by Drupal 8.0's release date.
Our guiding principles during this phase of development:
- We try not to change Strings in order to preserve translator efforts.
- We try not to change UI in order to preserve documentation efforts.
- We try to support RC to RC upgrades, in order to help early adopters.
- We try to avoid breaking APIs except in the case of a critical issue.
Special thanks to Nathaniel Catchpole (catch), Angie Byron (webchick), Alex Bronstein (effulgentsia) and Moshe Weitzman (moshe) for their input. I'll continue to evolve these guidelines so more feedback is always welcome.
Very exciting news from the White House today.
Last night President Obama fulfilled his promise to release the code behind "We the People", a Drupal-based application that enables the American people to directly petition the President of the United States on issues they care most about. The release follows a commitment the President made to the United Nations to share the technology behind this platform “so any government in the world can enable its citizens to do the same".
In October of 2009, WhiteHouse.gov was relaunched on Drupal. Two years later, the White House launched We the People on Drupal, a big step forward for Open Government. While governments haven't traditionally recognized the importance of the grassroots, word of mouth organizing that thrives on the Internet, We the People encourages grassroots citizen engagement.
Even more exciting is that if you are an Open Source developer, you can get involved with improving how your government actually works. Needless to say, I'm thrilled to see Open Source and Drupal changing the world in a positive, powerful way.
The newly released code is packaged as a Drupal install profile. The profile is currently tailored to the White House's website but every Github member can issue pull requests to make it more generally useful. The Petition install profile can be cloned, forked or downloaded from the White House's Github repository.
Today it was announced that Acquia is the eighth company on the Inc 500. This means we are the eight fastest growing private company in the United States. With nearly 7 million private companies in the US, being honored as number eight is an enormous accolade. In addition, we are the first software company on the list, making Acquia the fastest growing software company in the US. The current print edition of Inc Magazine also has a two page profile on Acquia.
This honor is attributed to each and every Acquian. I’m so proud to be part of such a hardworking and dedicated team! Go Acquia! Go Drupal!
The Spark distribution is a Drupal 7 distribution which aims to prototype cutting-edge authoring experience improvements that we hope to propose for inclusion in Drupal 8 core. Since we announced Spark back in May, we've shown videos of prototypes of inline editing, responsive layout building and mobile administration. The rest of the Spark team (Angela Byron, Kevin O'Leary, Wim Leers, Gábor Hojtsy, Jesse Beach, Preston So and Dharmesh Mistry) has also been working hard to make these designs a reality.
There has been a lot of great progress over the past months, and with the release of Spark 7.x-1.0-alpha4, Spark is now ready for some community testing! Each module/theme that Spark builds upon is a separate, standalone contributed project that can be integrated into existing sites. This alpha release includes:
- Inline Editing, courtesy of Edit module. You can click into a node, switch the “View / Edit" toggle in the toolbar, and then click directly into any field to edit its contents, instead of having to be redirected to the backend.
- True WYSIWYG, courtesy of Aloha Editor. Edit your rich text with your theme's direct styling through the inline editor. It even works with images + captions, links directly to content in the site, and has basic support for tokenized strings.
- Responsive Layout Builder, courtesy of the Layout and Gridbuilder modules. You can configure layouts for separate breakpoints (e.g. Mobile, Tablet, Desktop) and even define your own grids for them to snap to. These technologies layer on top of Panels,though it's been architected so it could be integrated with other layout solutions as well.
- New admin theme, brought to you by Ember. This brings some nice light styling on Drupal core's Seven admin theme as well integrating the Admin module to better support mobile devices. A more fleshed out mobile toolbar and administrative experience is slated for implementation soon.
If you'd like to try the distribution out without downloading and installing it, check our demo site at http://demo.sparkdrupal.com. (Note that since this site is open to anyone, it might look a bit funny at any given time. If things are really broken, please check back later.)
There is still much to do, but hopefully this release will provide a good understanding of the direction Spark is taking, and what we hope to propose for inclusion in Drupal 8 core. We greatly welcome feedback, bug reports and patches in the Spark issue queue.
At DrupalCon Munich next week, we'd love to talk more about how we can move some of these things into Drupal 8 core. We've setup various Spark sessions and BoFs at DrupalCon Munich to plan and brainstorm about this.
After a lot of discussion and testing, we decided to adopt the Aloha Editor as the WYSIWYG editor for Spark, and possibly for Drupal 8 core. Check out Wim's blog for the details. In short, it is the best HTML5 based WYSIWYG editor; fast, well-written and future-proof.
Here is a screenshot of our latest designs of how we envision integrating the Aloha Editor in Spark on a mobile device:
By tapping into a rich text field such as Body, a toolbar comes up with two tabs with editor buttons below: Format (containing buttons such as Bold, Italic, Left/Right Align, and Lists) and Insert (for Links, Images, and the like).
I also wanted to give a big thank you to Haymo Meran, creator of Aloha Editor and Director of Product Experience at Gentics Software GmbH, both for hosting a Drupal/Aloha collaboration sprint at his company's offices in Vienna last month, and also for changing the license of Aloha Editor to GPLv2+ (from AGPLv3) so that it could be used with Drupal!
It's an incredible gift to the Drupal project and the Open Source community at large. Thanks!
For the foreseeable future, Mollom will continue to be offered as it is today. I will continue my role as general manager of Mollom, Ben will continue to lead the development of our products and the Mollom team will remain unchanged. If you are a user or customer of either Mollom or Acquia, everything will remain exactly the same.
When Ben and I started Mollom almost 5 years ago, we wanted to do something important. While most people were trying to figure out the social web, we were paddling out ahead of the wave, knowing that many websites would soon have to deal with increasing amounts of spam and content moderation. In the past five years, we have helped tens of thousands of people fight spammers on their websites, including some of the world's leading organizations.
We have blocked almost a billion spam messages since we started. It has been very rewarding for us to see that we have helped make the web a slightly better place. At the same time, we also built a healthy business. We successfully bootstrapped Mollom, and organically grew a team of 6 people.
The social wave keeps on growing; we're helping more and more people and organizations every day. But now that social wave has grown so big, we can't rest on our laurels. There are more business opportunities to explore, some of which we have been working on for a while.
At the business level, it made a lot of sense to merge Mollom into Acquia. Ben and I were looking to raise capital for Mollom to help fund future product development and expand our operations. It was clear that it would require a long-term commitment of my time – just at the point when I wanted to focus more on promoting Drupal globally and driving Acquia's growth and expansion. By having Acquia acquire Mollom, I can still be a part of Mollom, and Mollom could receive the resources to accelerate our efforts and create an even more exciting future for Mollom. It also allows me to double down on Drupal and Acquia. In short, I'm really excited to have Mollom as part of the Acquia family.
Keep an eye on us!
Today, I'd like to share an HTML/JS prototype we've created for a mobile toolbar and dashboard for Drupal that we hope to include as part of the Spark distribution and then propose for Drupal 8 core as part of the Drupal 8 Mobile Initiaitve.
Drupal 7's default administration tools (e.g. Toolbar module and Shortcut module) were not designed in a “mobile first" way, and as such can be difficult to work with on tablets or smartphones. For example, here is a screenshot of what happens to the Toolbar and Shortcut modules when using a responsive version of the Bartik theme on an iPhone:
On an iPhone or other mobile device, the default Drupal 7 toolbar and shortcut bars both wrap, taking up nearly a third of the screen.
We set out to do justice to the complexites of Drupal's administration layer while accounting for the constantly evolving universe of devices. We think what we've come up with is scalable, responsive, and usable.
Here is Preston So, author of the prototype, demonstrating the functionality in a short, 7 minute video:
As we begin work on this feature, it will live at the Mobile friendly navigation toolbar project as a contributed module for Drupal 7 first. If these changes are well-received, I hope we can target this functionality for Drupal 8 core, as a replacement for the Toolbar and Shortcut modules.