Over the past two years, we've built Drupal 8 into what will be the most flexible, future-proof Drupal version ever. Core developers have contributed thousands of hours of work to expanding Drupal 8's capabilities and modernizing our APIs.
We're several months into Drupal 8's API completion phase, and we're releasing monthly alphas as we nail down key APIs, refine the developer experience, and continue vital work on performance. To finish Drupal 8, we must focus on essentials, so I'd like to ask the Drupal developer community to look ahead to the next big step: the first Drupal 8 beta.When does alpha become beta?
Earlier in the year, we announced that Drupal 8's first beta would be released once we had a stable data upgrade path from Drupal 7. At DrupalCon Prague, however, the Drupal core developer team made a bold decision: instead of using Drupal's update.php database update script to convert Drupal 7 sites to Drupal 8 on the fly, Drupal 8 core will instead include a robust data migration API (based on the popular migrate module) to migrate data from existing sites into new Drupal 8 installations. This means that Drupal 8 core will provide reliable, extensible migration from Drupal 6 as well as Drupal 7. We believe this to be important for organizations running older versions of Drupal can reliably modernize their sites.Data migration no longer blocks a beta release
In order to make this important data migration change possible for Drupal 8, the initial Drupal 8.0 release will be primarily intended for building new Drupal sites, and the finished data migration path for existing Drupal 6 or 7 sites may be provided in a later Drupal 8 release, like Drupal 8.1. (For more information on how we might improve the Drupal release cycle after the release of Drupal 8, see the proposal to manage the Drupal 8 release cycle.)
This means that a data upgrade path from Drupal 7 is no longer a prerequisite for releasing Drupal 8.0-beta1. Instead, we will focus on what testers and contributed module authors most need from a Drupal 8 beta: (1) a stable data model and (2) stable critical APIs.Stable data model
A stable data model means that developers should not need to perform data migrations between beta releases of Drupal 8 (except where necessary to resolve critical issues). The Drupal 8 data model includes database schemas, file-based configuration storage, and storage services like the Entity and State systems.Stable critical APIs
To provide contributed module developers with a useful milestone for module porting, beta 1 will include stable critical APIs. These are fundamental APIs that most or all contributed modules depend on, including the configuration system, the Entity and Field API, the Plugin API, and the Routing and Menu systems.
Other API changes approved by core maintainers will continue through the end of the API completion phase, but after the first beta, we will shift from away removing deprecated code and instead retain more backward compatibility layers. (Module/theme developers who wish to go through the porting process only once should wait for the first release candidate.)What issues are blocking beta1?
Drupal core maintainers determine which specific issues must be resolved to meet the criteria above. We have worked with core developers to identify a list of beta-blocking issues. There are currently 48 of these "beta blockers" outstanding. As you can see, there are many difficult problems in this list that need to be solved. We need your help to resolve these issues so that we can release beta1 and expand Drupal 8's reach to new testers and contributors.It's focus time!
While the end of Drupal 8's development cycle is in sight, there's still a lot of work to do. Now more than ever it's essential to focus on the critical issues that will bring Drupal 8 closer to release. If we don't, we risk pushing Drupal 8's release off for many more months. The sooner we create a beta, the sooner we can release Drupal 8 to the world.
Many people looking forward to Drupal 8's release aren't sure how best to help out. I'd like to ask all sub-system maintainers to watch their sub-system's issue queues closely to help new contributors triage issues and fix bugs, especially for beta-blocking issues. I'd also like to ask everyone to review patches carefully, make only necessary API changes, and document APIs clearly. Or, if you aren't able to work on Drupal 8 issues directly, consider sponsoring core developers for Drupal 8 contribution.
Help us make Drupal 8 the best release of Drupal yet by working on our alpha releases and toward a Drupal 8 beta!
Over the past twelve months, I’ve become a bit of an obsessive follower of Bitcoin. It started after I read Satoshi Nakamoto’s original Bitcoin paper. It was a fascinating read and my first introduction to crypto-currencies. I even had a couple of lunches in Boston with Gavin Andresen, Bitcoin’s current project lead.
I was close to buying some Bitcoin when I first got interested, but backed off. It was too bad because Bitcoin's value increased from $13 a year ago to around $1,000 at the time wrote this: a 4,000% increase in 12 months. I didn't buy my first Bitcoins until a month ago. I bought them with some reluctance but I figured that people felt a certain reluctance when paper money first came along. But I bought them because to me it seemed like Bitcoin could work and also because I wanted to have a better understanding of what it was all about.
Bitcoin is a purely digital currency. There are no records of Satoshi's identity so no one knows who invented it, no one controls it and it is not backed by gold. It is something akin to a digital version of gold. It's fascinating. At the core of the Bitcoin system is a global, public log, called the "blockchain", that records all transactions between Bitcoin clients. A user can send Bitcoins to another user by forming a transaction and committing it to the blockchain. The blockchain is maintained not by a central body, like a central bank, but by a distributed network of computers, called "miners". Everyone can be a miner, and the miners collectively record and verify all transactions.
Compared to traditional banks, the advantages of Bitcoin are significant. Bitcoin payments can be made at any day of the week, any time of day to anywhere in the world. The fees and delays involved are small compared to those imposed by banks; pennies compared to dollars and minutes compared to days. And unlike paper money, it is unforgeable. Unlike gold, its supply is perfectly verifiable. It is also immune to inflation: governments can't print more Bitcoins to pay off their debts.
The design and architecture of Bitcoin is both a curse and a blessing. The lack of central authority governing Bitcoin raises questions. Governments tend to enjoy power of observation; it makes it easier to fight money laundering, tax evasion and other crimes. As Bitcoin continues to gain popularity, governments may grow increasingly resistant and attempt to shut down Bitcoin. And banks don't like Bitcoin either. Money transfer is an important part of their business; it has almost zero risk, almost zero cost, yet provides them billions of dollars in revenue. In a world where Bitcoin is universally accepted, banks may have a diminished role.
The jury is out on whether Bitcoin is a fantasy destined for failure, or whether Bitcoin will underpin the future of finance. Some predict the value of one Bitcoin could climb to hundreds of thousands of dollars if it becomes universally accepted. While I risk losing some money, it could also turn out to be a massive investment home-run. I felt that the risk/reward decision made it a bet worth taking.
I certainly don't advise you to buy Bitcoin as I'm skeptical that Bitcoin will succeed. I predict Bitcoin to have an extremely bumpy ride, and at best, to follow Gartner's hype cycle. If Bitcoin ends up collapsing, I will be disappointed but I won't feel stupid. I already sold some Bitcoin and recouped my original investment; I'm long with my remaining Bitcoin.
So is Bitcoin a case of speculative greed, or a utopian cyber-libertarian ideology? In a world where everything is going digital, why not currencies? Bitcoin makes it faster, cheaper and easier to store and transport value. It was designed to overcome problems faced with traditional currencies and banks. At a minimum, Bitcoin has created a lot of debate throughout the world, and has shaken a stagnant banking market. Longer term, the concept of a crypto-currency makes a lot of sense to me. It is massively beneficial for the world that we can transfer money easier, faster and cheaper. I find it hard to believe that a hundred years from now, we'd still be digging up gold, and that we wouldn't have a global, digital currency to replace it.
If you believe a digital currency is the future of money, I'll leave you with one question: how would one launch a world-wide crypto-currency like Bitcoin? It can't be owned by a commercial organization, and I simply can't imagine all the world's governments work together to build and launch something like this. Creative disruption often comes from the outside, and not from the inside. It pretty much has to happen in a grassroots way, not unlike the way the Internet was created. Even today after 30 years, the Internet operates without a central governing body and is comprised of independent, voluntarily networks. It works well and changed the world.
For the International Day of People with Disabilities (IDPwD) today on December 3rd, I want to take some time to reflect on the Drupal community’s work to support universal access to information technology. Drupal is an inclusive community, both in how we interact with each other and in the results of our work.
We understand the need to create software that is accessible, both for consumption and production of content. Our accessibility statement opens by saying:
As an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.
Donna Benjamin and Jesse Beach wrote a great overview of the accessibility improvements efforts in Drupal 8. It will meet higher standards of access than our previous releases. As developers and site builders, we continue to incorporate new techniques and access technologies into Drupal. Accessibility to the core.
As a community, we're proud and thankful for the efforts of all those who have contributed time and energy writing, reviewing and testing patches aimed at improving the accessibility of Drupal. There is much work still to do. If you are able, please join the accessibility effort to make sure our next version is our best yet. Thank you!
I'm turning 35 today. 35 is a weird age. It feels like a milestone birthday; like I'm turning the corner into adulthood for good. Turning 35, it seems, is not without complications. I feel like I became part of the old folk whose cool is threatened by youngsters. Anxious, as I've so much left to achieve and experience.
And yet, I am following my passions and there is not much more I'd want. People have asked me what I'd like for my birthday. I'd love it if you gave me one of the following two things:
People wonder what we do at Acquia's Office of the CTO (OCTO). In order to provide some more transparency, I wanted to share how we plan to give back between today and the end of the year.Drupal 8 beta 1
Now that we're forgoing an upgrade path for a migration path, we need to redefine the release criteria for 'beta 1'. We also need to track the issues that block beta in order to help escalate the most critical of the critical issues. We will work with the Drupal 8 core maintainers to define and communicate these criteria, and help with timely patch reviews and issue management for beta-blocking issues.Migrate module in core
As a co-author of the Migrate module, Moshe will be assisting the core development team on the goal to get Migrate module functionality into core and support a Drupal 6 to Drupal 8, as well as the Drupal 7 to Drupal 8 migration path.Improve the Drupal 8 developer experience
We want developers to be productive and enjoy writing Drupal 8 modules, so we will be fleshing out the D8DX battleplan based on discussions at DrupalCon Prague, and working with others in the Drupal community to ensure that we fix the most important developer experience problems in preparation of Drupal 8's release.Develop learning resources
We will be working on a central resource on Drupal.org for developers to find the information they need in order to port their modules to Drupal 8, including documentation, tools, and other resources.Evaluate semantic versioning
There was a lot of talk at DrupalCon Prague about lessons learned in Drupal 7 and 8 and how to do better in the future. One such area of improvement is a release strategy that allows for iterative innovation in Drupal core every few months. We plan to work with other community leaders and the Drupal security team in order to come up with a strategy around this. A component of this strategy may be to adopt semantic versioning.Improve Drupal 8 performance
We will also dedicate the OCTO team's time to help the Drupal core community identify and fix some major performance issues in Drupal core.Authoring experience improvements
Major development efforts on the UX features the Spark team helped get into Drupal 8 core—WYSIWYG, in-place editing, mobile-friendly toolbar —are winding down. We still have work to do on fixing up some loose ends, and are committed to see this through. We will also backport the major Spark modules to Drupal 7.Communicate Drupal 8 progress
We aim to continue the weekly D8 progress reports that you can find at This Week In Core, and are actively seeking other core developers to help get these important posts out.A drop in an ocean
We're a handful of contributors in the OCTO and can only do so much. We will continue doing these things within a community of hundreds of other contributors and supporting their work in other ways. We're looking forward to much Drupal 8 progress in the next 3 months!
People ask me what it is like to be the head of a big Open Source project, and whether they should Open Source their project or not. I wanted to talk about that a bit more in this blog post so more people can pick up my answer.
Having been the project lead of the Drupal project for the past 13 years, I’ve watched my dorm-room activity transform into a community filled with passionate people all working toward the same goal: changing the world and making it a better place through open source.
Today Drupal powers more than 1.5 million sites. Drupal is a source of innovation for business and government. Most importantly, Drupal has helped individuals build a dream, giving smaller groups and organizations a bigger voice, as tools are democratized. But it has also allowed large businesses to develop new ideas, bring and build transformative experiences to the digital world.
The ambitious individuals who would lead the next generation of open source projects will experience moments of joy and excitement. It's exhilarating when your passion drives you to help create solutions to challenging problems. Your joy will be tempered with plenty of moments of frustration and doubt, as roadblocks may stand in your way during crucial points of development. But the successful leaders will be the ones who aren’t dissuaded from their work.
Creating a successful open source project requires much more work than writing good code. If your project is growing, then one day you'll start to see that you are a leader. You’re creating a vision, a culture, and inspiring people to come on board. This evangelism requires a lot of travel, conferences, fundraising, people management, project management and more. Make sure this passion is also within you.
I’ve had the opportunity to travel the world, evangelizing Drupal and have a leading role in a passionate, active community that is making a real difference. I’ve also founded a non-profit organization and a commercial company on that same promise.
As you start to build a community of participants who are willing to commit their time and passion to your project, you’ll soon realize that in life, the luckiest people in the world are those driven by the desire to be a part of something great. When you work in open source, you’ll be surrounded by people like these. Knowing you help make a difference and that hundreds of thousands of people depend on your project, helps you make sense of your commitment. So even on a bad day, it's still exciting.
The world would certainly benefit from having more Open Source, but its not a small undertaking as others come to depend on it. Only you can decide whether you have what it takes. When I started Drupal, I didn't really understand what I was getting myself into. It has been a lot of work, but knowing what I know today, I'd do it again. In a heartbeat.
Last week in Prague, I gave my traditional State of Drupal presentation. A total of 1,830 Drupalists were present at DrupalCon, a new record for our European DrupalCon!
In good tradition, you can download a copy of my slides (PDF, 31 MB) or you can watch a video recording of my keynote. The keynote starts at 11:42, but don't miss out on the singing carrots introduction. A video recording of the keynote is embedded in this post.
Liefste Moeke Hasselt,
Vandaag is het een vreemde dag. Ik kan helaas niet bij je zijn maar ik denk aan jou en deel de pijn.
Ik denk terug aan de liefde die je ons hebt gegeven. Met goedheid en lieve zorgen heb je ons omringd.
Kon ik nog maar een keer goed met je praten, of kon ik je maar laten zien hoe ik mijn leven zou gaan leiden.
Maar vrees niet, want je hebt ons een erg goed voorbeeld gegeven. Je was een vrouw met een groot besef van plicht. Bedachtzaam, bescheiden en tevreden -- die dingen staan nu ook in ons hart en in ons verstand geschreven.
Vandaag is het een vreemde dag. Verdrietig om het gemis, dankbaar voor de goede herinneringen, en trots op wat je ons hebt gegeven.
Moeke Hasselt, geniet van je rust, verlost van alle pijn, en van eindelijk bij Vake Hasselt te zijn.
Je kleinzoon, Dries
I'm excited to announce that Acquia is launching Acquia Cloud Free, a no-cost development sandbox for Drupal development. While Acquia has always had a freemium offer for development purposes, it had an expiration date, and it required a credit card. We've changed that with Acquia Cloud Free. Acquia Cloud Free comes packed with great tools including, but not limited to:
We've put a lot of thought and effort into creating the Acquia Cloud platform and continue to invest it in heavily. As a result, we have seen tremendous adoption. I believe that giving everyone access to a free Acquia Cloud development sandbox is one way we can give back and help grow Drupal. Give it a try if you want!
The blog post below was a guest article I wrote for Inc Magazine and was published in September 2013. It has been a while since I shared a startup lesson on my personal blog so I'm cross-posting my article here.
When I started working on Drupal in my college dormitory 12 years ago, I had no idea that one day it would be used by 2 percent of the world's websites. What is even more exciting is the open source community that has grown up around Drupal.
I co-founded Acquia six years ago to support the growing number of organizations that rely on Drupal, and also co-founded Mollom to solve the spam moderation challenges for website owners. Six years later, Mollom was acquired, and Acquia has almost 400 employees. As I've encountered challenges every step of the way. Here are three lessons learned.1. Think big
So often I meet entrepreneurs who are working on a startup concept. They have a great idea and a business plan to bring it to market, but they're thinking too small about what they're trying to do.
I believe companies are most successful when they have a mission to change the world. When you set ambitious goals, you'll better position yourself for success. You become what you believe.
Being shortsighted can be a big barrier to success, because you can easily miss the window to capitalize on an opportunity. It's why I founded Acquia in the United States; I immediately had access to a larger market. We moved quickly to be a global company to maximize our opportunity, and it's made all the difference.2. Fail fast
"Fail fast, succeed faster" is a philosophy that's been adopted across the company at Acquia. It's perhaps counter intuitive, but the idea is that in building a startup, you're going to fail. There will be problems, and the faster you run into them, the faster you can learn, adjust, and grow.
Implied in the fail-fast philosophy is that you'll be open to failure, and that can be hard for entrepreneurs who are so focused on success. People don't like to fail, so they're not inclined to celebrate their failures and embrace the lessons learned. Yet doing so means you'll more quickly make the needed – and often painful – adjustments to get on the right path faster.
In the initial business plan for Acquia, we expected to support a specific distribution of Drupal that we'd closely manage. Early prospects told us repeatedly it was a great strategy, yet when we took our offer to market, the buyers weren't there. We realized very fast that our business plan needed a big change, that we needed to support Drupal in whole. It was a terrifying proposition at that stage of our business, but we realized that was what the market needed most. We made the change, and it quickly put us on a successful course.3. Passion makes the difference
I think some people get inspired to launch a startup because of its potential rewards, but launching a successful business starts with having a passion to solve a problem. I was passionate about building websites; it was my biggest hobby before it was ever a business opportunity.
When we started Acquia, our lead investor told me the key to a successful startup isn't in a good idea, but rather is in having a good team. A good team will figure out how to make something great happen. They'll pivot, they'll change, and they'll claw their way to success. Find talented people who share your passion, and together you'll find your way toward building a great business.
There has been a lot of chatter about Drupal 8. Will Drupal 8 be performant? Will Drupal 8 be easy to develop modules for? Will I have to learn Symfony? I want to address these concerns and explain why Drupal 8 introduces such big changes.Lessons from the past: the pain before the gain
The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.
The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to this change. I first wrote about it in 2006 when trying to get Drupal 4.7 released:
"So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off."
Drupal 7 is a fantastic CMS, but at the same time there are some fairly big limitations, including an incomplete Entity API, a lack of separation between content and configuration, leading to deployment challenges, a lack of separation between logic and presentation in the theme layer, and more. We created solutions for those challenges using contributed modules, but those solutions were in many cases incomplete. In Drupal 8, we decided to tackle a lot of these problems head-on, through the Configuration Management Initiative, the Twig templating layer, and a complete Entity API.
The web landscape has also dramatically changed around Drupal since January 2011, when Drupal 7 was released. Mobile browsing is ubiquitous, and so are third-party services that people may want to integrate their Drupal sites with. Web site users expect a much higher bar when it comes to ease of use. We anticipated these trends and as a result, we spent the past 2.5 years working on Drupal 8's mobile features and user experience improvements.
But are all these great improvements enough?We need to modernize Drupal 8
One of our biggest challenges with Drupal, is that it is hard for organizations of all sizes to find Drupal talent (developers, themers, site builders, etc). Drupal 7 didn't address this problem (e.g. we held on to procedural programming instead of object-oriented programming), and in fact made it a bit worse with the introduction of even more "Drupalisms" (e.g. excessive use of structured arrays). For most people new to Drupal, Drupal 7 is really complex.
The most effective way to address the Drupal talent issue, as well as the complexity issue, is to bring Drupal in line with modern frameworks and platforms, so there is less Drupal-specific knowledge to learn in order to become proficient. We decided to adopt modern PHP concepts and standards, object-oriented programming, and the Symfony framework. While a lot of the Drupal concepts (Fields, Views, Entities, Nodes) continue to exist in Drupal 8, they are now implemented using object-oriented programming design patterns.
The advantages and disadvantages of object-oriented programming are well-understood. The disadvantages are size, verbosity, the amount of work it takes to write (including the design planning that goes into it) and slower performance. For people new to object-oriented programming there may be a steep learning curve; some of the key programming techniques, such as inheritance and polymorphism, can be challenging initially. The advantages are encapsulation (both to hide implementation details and to avoid tampering with internal values), faster development thanks to re-use, extensibility, and better maintainability. Compared to procedural programs, object-oriented programs are easier to maintain, extend and refactor. So although a lot of work is spent to write the program, less work is needed to maintain it over time.
For Drupal 8 this means that the code will be more abstract, more verbose, and slower, yet also be more maintainable, more modular, and more accessible to non-Drupal developers. The end result is that Drupal 8 should help us attract new people to Drupal in a way Drupal 7 didn't.
This is exactly what happened with other projects like Symfony; Symfony 2 was a complete rearchitecture of Symfony 1. A lot of people were alienated by that, yet at the same time Symfony 2 took off like a rocketship. The same thing has happened with the major releases of Drupal as well, despite how much change each one brings.Change is scary for the existing Drupal developers
However, as we get closer to the release of Drupal 8, existing Drupal developers have become increasingly aware of the massive changes that Drupal 8 will bring. This has resulted in some fear; some people feel like they have to re-learn everything they know, and that developing for Drupal 8 has changed to the point where it's no longer fun. This fear is completely understandable. Change is hard, it can be scary, and often takes a long time to be absorbed.
But even if we completely streamlined the Drupal 8 developer experience, Drupal 8 will still look and work radically different under the hood. As mentioned, there are advantages and disadvantages to object-oriented programming and modern design patterns. But if we care about the long-term success of Drupal, we can't preserve the past. The risk of sticking with the old Drupal 7 architecture is that we won't be able to attract many more Drupal developers, and that over time, Drupal will become the odd one out.There is a lot of work left to be done
Part of the fear out there is well-founded because in the current state of development, Drupal 8 isn't good enough. While there are many things to like about Drupal 8, I'm also the first to admit that we have work to do on the Drupal 8 developer experience (as well as performance) before Drupal 8 can ship. Creating a well-designed object-oriented application takes more time and design work than creating a procedural one. Some major improvements have already landed, but we're still working hard on improving the developer experience. We need more help, especially from Drupal 7 developers, on how we can make Drupal 8 more approachable for them. I'm not afraid to make major API changes if the developer experience improvement is suitably large. So if you have concerns about Drupal 8, now is the time to step up and help. In return, I promise we'll work on Drupal 8 until it is ready. Thank you!
Many organizations adopt Open Source for reasons like flexibility and agility. Everyone needs to do more with less. But in government, Open Source drives both civic engagement and government participation like never before. Because of digital, the world feels much smaller and more connected. And Open Source gives people the opportunity to rally around a cause, no matter where they live.
Think about how we petitioned our government before we had the We The People website. I bet you have to think pretty hard about how it was done (I do!). Now, a website has brought to life the First Amendment rights of U.S. citizens. Millions of people's voices are heard. People pull together based on common concerns. The White House built We The People using Drupal and shared the code on GitHub, opening up the opportunity for other governments to easily create their own online petitioning systems.
Now, all kinds of open government data made available through the Data.gov project makes it possible for any developer, anywhere, to create a civic app. These apps have made us see our cities and towns in a different light.
Open City is one example of a group of local volunteers who create Open Source apps using government data. While the group is based in Chicago, the idea is that any city can grab code from an Open City app and make it their own.
Here are a few interesting examples: Clear Streets tracks a city's plows in real time. Living outside of Boston, I know we could use an app like that! Crime in Chicago lets citizens compare crime statistics in certain areas of town, which could be useful for people making decisions about where to move their families.
What is perhaps the most gratifying is that as open-source developers, we can collaborate on projects and help people around the world. It's part of what gets us out of bed in the morning. Earlier this year, participants in DrupalCon Portland launched a website in 24 hours to help people in Moore, Oklahoma, find transportation and housing after the tornado. Two weeks later, the site was discovered on Twitter in Germany and was repurposed to help people affected by the flooding in northern Europe. This type of project inspires us all to see how technology can make an immediate difference.
Other events, such as the National Day for Civic Hacking, encourage developers to use open government data to "collaboratively create, build, and invent". The idea that hackathons can help build and create a healthy, citizen-powered technology ecosystem within government is relatively new, and full of promise. Tim O'Reilly believes that government can escape the "vending machine" mentality (citizens put in tax dollars and get out services) by thinking of "Government as a Platform" for participation. I couldn't agree more.
Open Source ideals are already spreading in governments throughout the world, with good reason. A global network of developers is motivated to help. It's one of the best examples of civic engagement. As digital citizens, we all now have the power to contribute. One person's time and talent can make a huge difference. That is a movement I'm proud to be a part of.
(I originally wrote this blog post as a guest article for VentureBeat. I'm cross-posting it to my blog.)
Do you have questions about the upcoming Drupal 8 release? On Thursday, September 26 at DrupalCon Prague, I'll be moderating a question-and-answer core conversation with a panel of Drupal 8 leaders, including core committers and initiative leads. Questions are submitted in advance online, and anyone can submit a question. I will curate the submissions to ask the panel the most interesting and relevant questions. We'll also publish the full list of submissions after DrupalCon (with personal information removed) so that the community has a chance to get answers for questions we don't have time for during the session.
This is a rare opportunity for the community to communicate directly with the decision-makers who are shaping Drupal 8 into the best release of Drupal yet. Help us make the most of of it -- submit your questions now!
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.Closing thoughts
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!