WordPress 7.1 Release Retrospective

A huge congratulations, and a giant thank you to everyone who helped make WordPress 7.1 happen! The release was only made possible by your dedication and hard work. You all are heroes.

Now that the development cycle is over, it’s time for a retro. You’re invited to share your thoughts on the 7.1 cycle, on processes, squad, or anything else about the release cycle. I know you all have a lot to say after that whirlwind, so please do. Feedback loops help uncover what is and is not working so that the release process can be improved. 

Please share your feedback using this form or by dropping a comment below by September 30th. Even contributors who did not contribute directly to the release are welcome.

Someone who was simply watching the release will have thoughts and opinions that vary from someone who was more heavily involved. It’s important for diverse perspectives to be represented in feedback for big picture clarity. So no matter who you are, please speak up.

The survey is not anonymous, but submissions will be anonymized in the follow up summary. Your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is only needed for any additional questions.

The form and comments will be open until September 30, 2026, and a summary of feedback will be published soon after.

Thank you for taking the time to give your valuable feedback, and thank you again for your amazing investments in 7.1 “Mary Lou”. Together, future release cycles will be even better.

Props to @krupajnanda and @annezazu for the pre-publish review.

#7-1, #release, #release-process

WordPress 7.0 Release Retrospective

A huge congratulations, and a giant thank you to everyone who helped make WordPress 7.0 happen! The release was only made possible by your dedication and hard work. You all are heroes!

Now that the development cycle is over, it’s time for a retro. You’re invited to share your thoughts on the 7.0 cycle, on processes, squad, or anything else about the release cycle. I know you all have :a lot: to say after that whirlwind, so please do! Feedback loops help uncover what is and is not working so that the release process can be improved. 

Please share your feedback using this form or by dropping a comment below. Even contributors who did not contribute directly to the release are welcome.

Someone who was simply watching the release will have thoughts and opinions that vary from someone who was more heavily involved. It’s important for diverse perspectives to be represented in feedback for big picture clarity. So no matter who you are, please speak up!

The survey is not anonymous, but submissions will be anonymized in the follow up summary. Your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is only needed for any additional questions.

The form and comments will be open until July 20, 2026, and a summary of feedback will be published soon after.

Thank you for taking the time to give your valuable feedback, and thank you again for your amazing investments in 7.0 “Armstrong”. Together, future release cycles will be even better!

Props to @4thhubbard and @jeffpaul for the pre-publish review.

#7-0, #release, #release-process

WordPress 6.9 Release Retrospective

Congratulations to all who helped make WordPress 6.9 possible!

Now that the release cycle is complete, you’re invited to reflect and share your thoughts on the release cycle, release processes, release squad, or whatever else is on your mind. Feedback loops are critical to learning what works and what doesn’t so that the teams involved can iterate on the processes to improve for future releases. 

Everyone is welcome to submit feedback about the release using this form, even contributors who did not contribute directly to the release itself.

A member of the community that casually observes a release cycle will have very different thoughts and opinions than someone who was heavily involved on a weekly or daily basis. The more viewpoints and backgrounds represented within this feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop the better. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous, but anything submitted will be anonymized before being shared in a post summarizing the results. Your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is required just case the person processing the responses needs to reach out to you for further clarification.

The form and comments will be open until January 15, 2026. A follow-up post with the collected, anonymized results will be published shortly after.

Again, thank you for your contributions to 6.9 “Gene,” and for taking the time to provide valuable feedback to help make future releases even better!

Props to @amykamala, @desrosj for the peer review.

#6-9, #release-process, #retrospective

WordPress 6.7 Release Retrospective

Congratulations to all who helped make WordPress 6.7! Now that it has launched, you’re invited to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases. 

Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.

The form and comments will be open until January 13, 2025. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.

Again, thank you for your contributions to 6.7 “Rollins,” and for taking the time to help make future releases even better!


Props to @priethor for the peer review

#6-7 #retrospective

#core, #release-process

WordPress 6.6 Release Day Process

Preparation for the WordPress 6.6 release is underway.

This post shares the release process, including the timeline and how you can help.

Release Timeline Overview


Dry Run

The Dry Run is a key event as a final walk-through for the final release. As noted above, this is scheduled for July 15, 2024, in the #core Slack channel.

What happens usually during the dry run?

  • Bug reports are reviewed to determine if any are critical to warrant another 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). (release candidaterelease 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).).
  • Checks and any necessary updates are made in the src/wp-adminadmin (and super admin)/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.

If the results are acceptable, the release will go into a 24-hour code freeze period.

24-Hour Code Freeze 

After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.

What does this mean?

No source code for 6.6.0 (i.e., in the 6.6 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".) can be changed during these 24 hours.

What happens if a critical 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. is reported during this period?

The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

  • If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
  • If not, then the bug is targeted for 6.6.1.

The Release Party 📅

The WordPress 6.6 Release Party will start on Tuesday, July 16, 2024, at 16:00 UTC in the  #core Slack channel.

The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.

Please note releasing a major version requires more time than releasing a 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com will also need testing.

You can start this early by running the WordPress 6.6 RC3 packages, which are built using the same method as the final packages.

During the release party, options will be provided on how to help test the release package.

Tips on What to Test

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.2.2, 6.3.0, 6.4.0, 6.4.1, 6.4.2, 6.5.5 and 6.6 RC3, as well as any other versions possible.
  • Remove the wp-config.php file and test a fresh install.
  • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does multisite upgrade properly?

Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.6 post.


Thanks to @audrasjb, @marybaum, and @davidbaumwald for the peer review.

#6-6, #core, #release-process

WordPress 6.5 Release Retrospective

Congratulations to all who helped make WordPress 6.5! Now that it has launched, I invite you to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases. 

Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.

The form and comments will be open until April 26th, 2024. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.

Again, thank you for your contributions to 6.5 “Regina,” and for taking the time to help make future releases even better!


Props to @akshayar and @marybaum for the peer review

#6-5 #retrospective

#core, #release-process

WordPress 6.5 release delayed 1 week

Based on community feedback on the Unblocking WP6.5 – Font Library and Synced Pattern Overrides and Font Library follow up posts, there has been a change to the WordPress 6.5 release schedule and a final change to the Font Library. 

The release of WordPress 6.5 will be delayed one week and is now scheduled for release on Tuesday, April 2nd, 2024.

The delay is to accommodate the following:

  • The directory for font storage will be changed to wp-content/uploads/fonts.
  • The Editor team will work on including fixes for a select few high impact bugs that have been identified with the Font Library feature in the upcoming 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/ 18.0.0 release. This ensures they will receive some testing before being considered for merge into trunk prior to WordPress 6.5 RC4.
  • An unplanned WordPress 6.5 RC4 is now scheduled for release on 28 March 2024 at 16:00 UTC with the updated font storage location and any other related bugs deemed critical to the release. This will be a normal release candidaterelease 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)., with the announcement being published on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ News blogblog (versus network, site) for extra reach.
  • The 1 week delay allows for ample time for testing, acknowledging that Thursday-Monday is a major holiday for parts of the globe.

Why the change?

This approach ensures that the greatest number of sites possible can benefit from the new Font Library feature without the need to install or configure anything.

While attempting to implement the originally suggested compromise, the sentiment from the trusted contributors involved was that a solution could not be shipped with a level of confidence that meets the standards that core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org hold themselves to in the remaining time before the originally scheduled release.

After evaluating the potential options and discussing the proposed solution, the most risk averse option was determined to be storing fonts in the wp-content/uploads/fonts directory.

Shipping a feature that requires additional configuration or technical knowledge isn’t in line with the guiding philosophies that have helped the project mature into the successful project that exists today. Part of the original post was a call to return back to those project philosophies, and something this change attempts to adhere to.

The Dry run post will be updated to reflect the schedule for the new release date of 2 April.

Post release

Following the 6.5 release, these items detailed in the original post should still be explored:

  • A roadmap will be published outlining where the project components are headed in relation to establishing new first-class concepts outside of previously established paradigms within the software (like breaking down themes into fonts, patterns, templates, etc.). Why was this such an important and impactful decision? What is the goal we are trying to accomplish? And how might it present itself again in the future?
  • A means to move the canonical location of the fonts directory. Should the wp-content directory become writable for a site, a safe path forward should be offered for its owners.
  • Explore whether additional checks should be added to Site Health.

Props to @desrosj, @davidbaumwald,@hellofromtonya, @chanthaboune, @peterwilsoncc, @priethor, @jorbin, @annezazu, @akshayar, & @courane01 for pre-publish review.

#6-5, #core, #release-process

WordPress 6.5 Release Day Process

UPDATE: Following Font Library-related discussion the release party has been rescheduled to April 2nd, 2024.

Preparation for the WordPress 6.5 release is underway.

This post shares the release process, including the timeline and how you can help.

Release Timeline Overview


Dry Run

The Dry Run is a key event as a final walk-through for the final release. As noted above, this is scheduled on April 1, 2024 in the #core Slack channel.

What happens usually during the dry run?

  • Bug reports are reviewed to determine if any are critical to warrant another 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). (release candidaterelease 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).).
  • Checks and any necessary updates are made in the src/wp-adminadmin (and super admin)/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.

If the results are acceptable, the release will go into a 24-hour code freeze period.

24-Hour Code Freeze 

After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.

What does this mean? No source code for 6.5.0 (i.e., in the 6.5 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".) can be changed during these 24 hours.

What happens if a critical 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. is reported during this period? The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

  • If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
  • If not, then the bug is targeted for 6.5.1.

The Release Party 📅

The WordPress 6.5 Release Party will start on Tuesday, April 2, 2024 at 18:00 UTC in the  #core Slack channel.

The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.

Please note releasing a major version requires more time than releasing a 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com will also need testing.

You can start this early by running the WordPress 6.5 RC4 packages, which are built using the same method as the final packages.

During the release party, options will be provided on how to help test the release package.

Tips on What to Test

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.2.2, 6.3.0, 6.4.0, 6.4.1, 6.4.2 and 6.5 RC3, as well as any other versions possible.
  • Remove the wp-config.php file and test a fresh install.
  • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does multisite upgrade properly?

Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.5 post.


Thanks to @davidbaumwald, @priethor for the peer review.

#6-5, #core, #release-process

WordPress 6.4 Release Day Process

Preparation for the WordPress 6.4 release is completed. This post shares the release process, including the timeline and how you can help.

Release Timeline Overview

  • The Dry Run completed on Monday, November 6, 2023. ✅
  • The 24-hour code freeze started on Monday, November 6, 2023, at 18:00 UTC  ✅
  • The release party is planned for . 📅

Dry Run ✅

The Dry Run is a key event as a final walk-through for the final release. As noted above, this was hosted on November 6 in the #core Slack channel.

What happens usually during the dry run?

  • Bug reports are reviewed to determine if any are critical to warrant another 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). (release candidaterelease 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).).
  • Checks and any necessary updates are made in the src/wp-adminadmin (and super admin)/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.

Since the results were acceptable, the release went into a 24-hour code freeze period.

24-Hour Code Freeze ✅

After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.

What does this mean? No source code for 6.4.0 (i.e., in the 6.4 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".) can be changed during these 24 hours.

What happens if a critical 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. is reported during this period? The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

  • If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
  • If not, then the bug is targeted for 6.4.1.

The Release Party 📅

The WordPress 6.4 Release Party will start on Tuesday, November 7 at 18:00 UTC in the #core Slack channel.

The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.

Please note releasing a major version requires more time than releasing a 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com will also need testing.

You can start this early by running the WordPress 6.4 RC4 packages, which are built using the same method as the final packages.

During the release party, options will be provided on how to help test the release package.

Tips on What to Test

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.1.3, 6.2.2, 6.3.0, 6.3.1, 6.3.2 and 6.4 RC3, as well as any other versions possible.
  • Remove the wp-config.php file and test a fresh install.
  • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does multisite upgrade properly?

Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.4 post.


Thanks to @meher, @rmartinezduque, @hellofromtonya and @akshayar for the peer review

#6-4, #core, #release-process

WordPress 6.3 Release Day Process

Preparation for WordPress 6.3 final release is underway. This post shares the release process, including the timeline and how you can help. The post will be kept up to date as the release process evolves.

Release Timeline Overview

The current plan is as follows:


Dry Run ✅

The Dry Run is a key event as a final walk-through for the final release. As noted above, the current plan is to start it on 2023-08-07 16:00. You are invited to observe and/or participate. It’ll happen in the #core Slack channel.

What happens during the dry run?

  • Review 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. reports to determine if any are critical to warrant another 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). (release candidaterelease 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).).
  • Checks and any necessary updates are made in the src/wp-admin/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.

If the results are acceptable, the release goes into a 24-hour code freeze period.

24-Hour Code Freeze ✅

After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.

What does this mean? No source code for 6.3.0 (i.e., in the 6.3 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".) can be changed during these 24 hours.

What happens if a critical bug is reported during this period? The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

  • If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
  • If not, then the bug is targeted for 6.3.1.

The Release Party 📅

EDIT: The Release Party will finally start on 2023-08-08 19:00 UTC

The release party on August 8th will start no sooner than 24h after the code freeze starts, with the exact time to be determined accordingly. You are invited to observe and/or participate. It’ll happen in the #core Slack channel.

The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.

Please note releasing a major version requires more time than releasing a 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com will also need testing.

You can start this early by running the WordPress 6.3 RC3 packages, which are built using the same method as the final packages.

During the release party, options will be provided on how to help test the release package.

Tips on What to Test

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.1.3, 6.2.2, and 6.3 RC3, as well as any other versions possible.
  • Remove the wp-config.php file and test a fresh install.
  • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does multisite upgrade properly?

Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.3 post.


Thanks to @chanthaboune for the peer review

#6-3, #core, #release-process