Last week, we wrote about contributing to testing the first beta of WordPress 5.7. This week, WordPress 5.7 reached the third and final beta stage! The beta has kept the WordPress core team busy – especially Sergey and Tim, since they are directly involved with the release squad. Read more about what our team has been up to!
The WordPress release process in short
The work on a new WordPress release starts several months ahead of time. For WordPress 5.7, work began already in November, even before the release of version 5.6. In case you’re not familiar with the release process, here is a quick rundown of the stages we go through.
In the planning stage, a team – or “squad” – of focus leads starts to form. Before the end of 2017 and the release of WordPress 5.0, the whole process used to be done by one person, with a couple of helpers. Because the complexity of WordPress is growing, now a whole team works on each release to reflect the situation.
This is the stage where the team publishes the schedule and a call for tickets from the community. After the squad receives feedback from contributors, component maintainers, project and focus leads, the release scope can be published, so the whole ecosystem is informed of what will happen in the next release.
In this stage, contributors work on new features, and they fix bugs, both old and new. The development phase can last several weeks or months, depending on the scope of the release.
Features that fundamentally change WordPress Core, or need several releases to be ready, are called “feature projects”. There are several going on, and you can keep an eye on them on the dedicated features page. Maybe you will find something you would like to contribute to!
Next up is the beta stage. The number of beta releases is flexible, and it depends on how much time contributors need to spend on testing. For the WordPress 5.7 release cycle, the team scheduled three betas. Usually, there’s one week between each beta to give contributors enough time to test.
This is the stage where the WordPress release cycle is different from the traditional software release cycle: usually, the beta stage is for testing only, but WordPress also uses it to introduce bug fixes. Our team lead, Francesca, proposed to change this. Now, the community is discussing this to make sure that different extenders (the plugin and theme developers, agencies, SaaS companies, etc.) can express their point of view.
Release candidate stage
A release candidate is a fully functioning version of the software that we can potentially release to the public. At this stage, the team focuses on testing and making sure that there are no serious issues. We can’t introduce anything new; the team focuses on fixing bugs that contributors discovered during testing.
The new version is available to the public! You can update from your WordPress dashboard or download it from the WordPress.org website.
We don’t only work hard: on the date of each release, the release squad hosts a release party in the #core WordPress Slack chat! During the release party, it’s time for doing the final technical steps required but also for saying thank you to all the contributors and celebrate the result of their efforts.
The final steps that we need to take during the release party are:
- updating the version number
- packaging the update into a .zip file
- announcing that people can start testing the update
- testing the various ways that can be used to update WordPress
You can join too! Sign up for the WordPress.org Slack workspace.
Haiku and jazz
Code is poetry – and with the release of a beta or release candidate, it’s tradition to include a haiku. Before the first beta of 5.7, on the 50000th update to WordPress, Sergey wrote:
Thank you for the past Excited for the future We are #WordPressStrong!
Every major release is named after a jazz musician. The release lead chooses and announces the artist at the launch during the final release party. WordPress 5.6 was named after Nina Simone. We won’t know who the artist for 5.7 is until March 9!
Our weekly team update
Releases, releases, everywhere! I can summarize my week like that. I am not directly involved with the WordPress 5.7 release, but as the WordPress Core global team representative and the team lead of our core team at Yoast, releases occupy a large part of my time.
Right now, I am keeping an eye on WordPress 5.7 and help the release team getting it through the end line by mentoring and picking up tasks here and there. I am also deep into planning mode for WordPress 5.8. We don’t have a schedule yet for it, but I started pinging component maintainers – the contributors that take care of one of the many sub-groups that make Core – to hear about their plans for the next features.
Last week, my main focus was adding missing
@covers tags to PHPUnit tests in WordPress for more accurate code coverage tracking. I also continued reviewing tickets for the upcoming major release of WordPress, as part of my duties as the Core Tech lead. I made nineteen commits to WordPress Core, ran mission control for WordPress 5.7 Beta 2, led a meeting for new core contributors, and triaged new tickets incoming into Trac (the bug tracking system that WordPress uses).
With each new beta release of WordPress 5.7, this WordPress version is getting more and more polished. The About page design is the last major thing to be tackled by the design team, and they’re doing a great job working on that. I’ve turned my attention to documentation about the design release lead process, as I found that there wasn’t any. I’m writing a page for the Design Team Handbook that will hopefully better prepare future design lead candidates for this task.
As Full Site Editing (FSE) in Gutenberg is starting to take shape, we started having discussions about the future of themes both in-house and with community members. The consensus seems to be that we need a hybrid model to allow existing themes to slowly transition and take advantage of the things FSE has to offer. It’s exhilarating to see where the future of WordPress leads!
As mentioned in our team introductions, sustainability is my passion. So I am improving it a little every day by working on the frontend styles for the blocks. I am also experimenting with a proof of concept to generate skip-links for FSE themes automatically. This would be a huge improvement for accessibility.
I started this week by doing a showcase of full site editing for the team. We wanted to see how far full site editing is from the minimum viable product (MVP). There is a lot of work left to do, especially for template creation and workflows. It is exciting to see where the site editor is heading. My main focus this week has been testing and creating patches for WordPress 5.7.
This week, I continued working on the WordPress testing instruction document that my colleagues at Yoast and I created on contributor day. So, I’m harmonizing the document’s tone and splitting it into multiple sections, which will be published on the WordPress Core team handbook.