You are here
Since Drupal 8's API freeze was announced on July 1, there has been some confusion about what API freeze means, from core developers as well as module and theme developers starting Drupal 8 upgrades of their projects. This post clarifies the API completion process, and documents what different audiences can expect from Drupal 8's development cycle and when.
API freezing is a process, not a point in time
As noted in the original API freeze announcement, as well as the Drupal core release cycle page, API freeze marks the point at which API changes are only allowed when needed to fix a major or critical issue. The process of completing the necessary remaining changes, however, will take time, and while that is happening, many important APIs are still changing.
The chart below illustrates the API freezing process, as well as what various groups of people affected by Drupal 8 development can expect during the rest of the release cycle:
For core developers, July 1 marked the point at which core maintainers began to postpone API changes not necessary for solving critical and major issues to Drupal 9, so that module and theme developers who've already started porting their projects only need to keep up with changes that are sufficiently important to a healthy Drupal 8 release. We've labeled this part of the release cycle the "API completion" to clarify this process. During this phase, any proposed API changes must go through a process involving core committer approval. Core committers will increasingly restrict what sorts of changes are allowed as time goes on.
I'd like to start porting my module or theme now. What can I expect?
Module and theme developers are encouraged to start porting now so they can uncover critical and major API problems while they can still be fixed. But if you are hoping to go through the process of porting your module or theme only once, the best time for that is after the first release candidate (see "What can I expect for beta?" below). At that point, the number of critical issues should be at or just above zero, meaning API changes should be extremely rare and only occur if there's no other way to resolve a severe problem.
You can read a summary of the most important outstanding API changes, or view the ongoing list of approved API change issues to see if your module is affected by changes that are still in progress. The list currently includes many issues related to the routing system, the entity field API, and the theme system/markup. If your project touches these systems, you may want to hold off porting a while longer, or at least be aware that these elements (as well as others) are still in flux and might change significantly before Drupal 8 is released.
What can I expect from beta releases?
Beta 1 will still be the point at which we encourage any interested site builders to try out the beta and provide feedback on it, so it will include an upgrade path from Drupal 7 for testing. It's a great time for site builders to set up test sites in order to take Drupal 8 for a spin and provide feedback while things are still somewhat malleable. Just know that because Drupal 8 is still in development, critical upgrade path issues may arise that cause data loss, so make sure you're backed up!
Previously, we also identified beta as the point at which we'd have a stable API against which module and theme developers could port code. However, after evaluating the list of major and critical API changes still outstanding, we realize that those changes will take more time to complete than we would like to wait to release our first beta. Therefore, we now recommend that developers who are not interested in providing early API feedback on Drupal 8 wait until the first release candidate.
Release management is difficult, especially in a large distributed Open Source community like Drupal. Getting Drupal 8 released involves many people, many processes, and even technology challenges. The quality of the Drupal 8 release is really important so as a result, there are no hard-and-fast rules and we'll continue to adjust in the best interest of the Drupal project. I hope this update proves that point, and that it clarifies how and when we would like you to get involved. Let's make Drupal 8 our best release to date - in a timely manner!
There is a pursuit we all share; not having to deal with spammers. The promise of a clean spam-free web.
With that in mind, I'm pleased to announce that we released a new version of the Mollom plugin for WordPress. Mollom is an anti-spam solution for websites that offers some unique features not available in other solutions like Akismet. For example, the new Mollom plugin for WordPress ships with complete support for the Mollom Content Moderation Platform — enabling you to moderate all of your WordPress sites from a single unified interface.
This is a great feature for organizations that have many sites. If you have 20 WordPress sites and 10 Drupal sites, you can now moderate these sites from a single user interface that offers powerful moderation workflows.
The new WordPress plugin leverages Mollom's PHP library that implements Mollom REST API. The library is the basis for the Mollom module for Drupal but was designed to be reused by other systems. If you have a content management system other than Drupal or WordPress, you can also connect it with the Mollom Content Moderation Platform.
Give it a try! You may like it.
July 1st has arrived. As announced earlier, this marks the start of the Drupal 8 API freeze (formerly known as the "code freeze"). I'm very excited about how Drupal 8 is shaping up; it will be a much more powerful and easier to use Drupal. While there is a lot of work ahead of us, I feel good about moving forward with the next phase of the Drupal 8 development cycle.
The two main goals of the "API freeze" are (a) to resolve release-blocking issues known as "critical bugs" and "critical tasks" and (b) to provide developers with a stable API to port their modules from Drupal 7 to Drupal 8. This means that during the API freeze we will no longer make backwards compatibility-breaking changes to public APIs except when deemed that it is necessary to resolve important bugs or where the API has already been deprecated. Changes that do not break backwards compatibility are still allowed, including API additions, at the maintainers' discretion.
During this API freeze, we're also going to do a few things differently than we did with previous release cycles. I'll explain each of those changes below.
Deprecating Drupal 7 APIs
Currently, Drupal 8 includes backwards compatibility layers that support Drupal 7 APIs while we complete conversions of core modules to the new Drupal 8 APIs. An example is the routing support in hook_menu(), which will replaced by the Drupal 8 routing system. The Drupal 7 APIs are being marked deprecated in phpDoc, and contributed module developers should not use them because they will be removed prior to the Drupal 8 release.
Deprecating Drupal 8 APIs
When appropriate, maintainers can still add new APIs to Drupal 8 that deprecate existing APIs. In this case, the deprecated APIs will continue to be supported and not be removed until Drupal 9. This is to avoid breaking contributed modules that have been upgraded to Drupal 8 already.
Adding stand-alone features
A certain class of features may get committed despite being over our commit thresholds. The main criteria are that these features have to be self contained (no follow-up tasks) and easy to roll back (limited inter-module dependencies). If a single critical or major is filed as a result of these commits, we will favour rollback over going forward. As a result, these kind of features should have almost no impact on the rest of core development, nor introduce technical debt.
The road to the first beta
During the API freeze, we will also switch from publishing alpha releases to beta releases. This will happen when there are no known critical bugs in the upgrade path from the last Drupal 7 release.
Between API freeze and beta 1, removing temporary backward compatibility layers and deprecated Drupal 7 functions is allowed and encouraged. After beta 1, we get more strict about backward compatibility breaks (temporary backward compatibility layers and deprecated functions not removed by then might not be eligible for removal any more).
After more than 2 years of non-stop work, it is pretty exciting to enter API freeze. It is a big milestone for all of us. Frankly, Drupal 8 will be our best release ever, by far, and I can't wait to get it in your hands. But we can't get Drupal 8 released without you. Please take a moment of your time to download and try out the alpha releases. If you are a module developer, make sure the things that are important to you are working, and working well so you can start upgrading your modules the day we start releasing betas. If you find a problem, please report it. Every bug you uncover is a chance to improve the experience for millions of users. Thank you, and we hope to see you in the issue queues!
A month ago we started the Drupal 8 alpha cycle to encourage module developers to test out Drupal 8 and to try upgrading their modules. Today, we published the second alpha release of Drupal 8: Drupal 8.x alpha 2!
I think it is exciting that after years of hard work by many, we have now begun to post alpha releases.
The purpose of alpha releases is to allow module developers to identify API deficiencies while they can still be corrected. We want Drupal's API to be easy to learn, easy to use (even without documentation), hard to misuse, easy to read and maintain, and easy to extend. Good API design really matters and we only have one chance to get it right so please download the alpha release, try upgrading some contributed modules, and provide us feedback along with suggestions for improvement.
Time is of the essence as API changes to Drupal 8 are only allowed for a little longer. We're about to enter the polish phase of the Drupal 8 development cycle, where we will soon switch to beta releases and no longer allow API changes unless needed to fix release blocking issues. From then on, most API improvements will have to wait until Drupal 9.
Everyone dreams of making money while asleep. The term "passive income" is often defined as income that is received on regular intervals without requiring a great deal of work to sustain it. Usually some effort has to be put in upfront, but the payoff from passive income can last for years. Passive income is particularly relevant when it comes time to retire. Two techniques often recommended by financial planners are (a) rental properties and (b) dividend investing. Both can work well, not only as a retirement plan, but as a way to build steady income. Certainly the idea of collecting checks for the rest of your life with minimal effort sounds appealing.
Quite a few people that try to retire early are documenting their journey publicly. For example, Jason is trying to retire by 40 by investing in dividend growth stocks and Mr. Money Mustache retired at the age of 30 through rental properties. Many other great examples exist online; I love reading up on their stories and progress. There is a lot to like about their lifestyle too; a common theme among them is that they live frugally.
So what does this have to do with Open Source? I love Open Source and Drupal and would like to see even more contributors. I think a lot of developers would love passive income so they have the freedom to contribute to Open Source more, preferably even full-time. Many developers also live a frugal life; passive income may be a good option to explore. But also, what about a third passive income technique: (c) websites? I know several people who have a number of websites, some of which they haven't touched for months, yet they still bring in around $500 a month. Owning a few websites could provide a wonderful chance to earn passive income, and it so happens that many of us in the Drupal community have a talent for building websites ... Food for thought.
Two weeks ago at DrupalCon Portland, I gave my traditional State of Drupal presentation. A total of 3,500 were present at DrupalCon, a new record for DrupalCon attendance.
In good tradition, you can download a copy of my slides (PDF, 29 MB) or you can watch a video recording of my keynote (keynote starts at 14:00). The video of the White House guest appearance and the Drupal 8 demo video area also embedded in this post.
Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.
From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.
One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.
We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.
While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:
- WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
- Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.
For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.