WordPress 6.1 ‘Misha’ Retrospective

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.
Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.
Other questions? Here is a detailed handbook for contributors, complete with tutorials.

With WordPress 6.1 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our thoughts on the release process to learn, iterate, and make future releases smoother. ✨

Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.

The form and comments will be open until December 15th, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog (versus network, site) in January 2023.

Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!

Props to @desrosj for peer review

#6-1 #retrospective

Dan Soschin 5:53 am on November 19, 2022

I think the form still references 6.0 vs 6.1… but everyone should be able to figure out that we’re collected feedback on how 6.1 went. 🙂
- Héctor Prieto 12:35 pm on November 21, 2022
  
  Hi Dan! The original link to the form was pointing to 6.0, but this was fixed a couple of days later, and responses are getting to the 6.1 form. Could you confirm the link works well for you, too?
Bernie Reiter 10:30 am on December 14, 2022

As one of the Editor Tech co-leads for this release, I’ve found that the amount of work that was needed for manually backporting PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher code from GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. was quite substantial. We had a few fairly big new foundational features in this release (e.g. the Style Engine and Layout blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. support); while they were broken into smaller PRs to make them easier to review, it still took a while to land all of them, as there were some interdependencies that required some rebasing and adjusting.

Furthermore, things that work in Gutenberg sometimes break when ported to Core. For example, we spent quite some time debugging two issues with Global Styles not being applied to blocks. Fixing them caused some ripple effects that affected performance and kept us busy for the rest of the release cycle.

While the process of backporting JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. code from Gutenberg to Core is largely automated, it also wasn’t without friction. Following established practices, Editor Tech and Editor Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. co-leads would typically decide which Gutenberg PRs that were marked for backporting to actually include on a weekly basis, about 24 hours before each BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.’s and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).’s scheduled release party. The list of candidate PRs typically included between 20 to 25 PRs for each of those. (Only RC2 had fewer.)

We leaned a bit more on the permissive side; as a result, we were regularly asked to remove some of the changes we had approved. This meant reverting the relevant commits on Gutenberg’s `wp/6.1` branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"., and going through the publish-and-sync process again – often only shortly before the scheduled release party, leading to delays.
- Bernie Reiter 10:36 am on December 14, 2022
  Judging from conversations with other folks, I think there’s already some momentum to improve some of those processes! As for the backporting of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, I know that @hellofromtonya is working with @azaozz and others to make that more of a continuous process, long before the first BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..
  
  Per discussion with @priethor, it seems that we agree that it might make sense to break up the Editor focus into sub-projects and teams, so that people with more domain-specific knowledge can lead them during release cycles, avoiding the bottleneck of few Editor Tech co-leads that are in charge of all Editor features.
  
  Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. of candidate PRs from the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repo needs to be better streamlined. I can think of a few things that might help:
  - Triage earlier before the release party. (This might mean moving the release party to a later weekday.)
  - Have a CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. representative present at every release party, to make sure candidate fixes get the needed amount of scrutiny in time and don’t require reverting later.
  - Make triage issue-based, rather than PR-based. This would allow defining a number of issues that need fixing shortly after a Beta or RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)., and for contributors to prepare those fixes in time for the next Beta or RC.
  Finally, some technical solutions can help avoid some recurring issues. Examples include flagging gutenberg_ prefixes on each wordpress-develop PR, or increasing parity between Gutenberg’s and Core’s PHPUnit tests.
David Baumwald 6:26 pm on March 7, 2023

@priethor Hope you’re doing well. Would you mind giving a quick update on the status of the recap for the WordPress 6.1 Misha Retrospective that you’ve been working on? I’m just curious to see how things are coming along. Thank you so much for your hard work and dedication to the project!
- Héctor Prieto 1:20 pm on March 8, 2023
  
  Sure @davidbaumwald. There was an issue accessing the form during the first weeks, so the window to submit feedback was extended and overlapped with the 6.2 release phase.
  
  We are not receiving any more feedback, so I think it’s time to ship the recap post indeed 🙂

Comments are closed.

Welcome!

Communication

Share this: