Tag Archives: release-process

Héctor Prieto 5:12 pm on August 1, 2023
Tags: , , 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 5.6.20 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

Isabel Brison 4:44 am on August 1, 2023
Tags: , , release-process   

Proposal: improve the editor tech workflow for major releases

Following on from this conversation, let’s look at how this process can be run more smoothly!

The Problem

Updating coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. with the latest features 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/ 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 almost always causes problems and delays at release time. Historically, it has been done in a large batch just before 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. 1, and the volume of changes means there is a high probability of something going wrong in the process.

A brief look through the “retrospective“ tag shows this has been a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. pain point for a while.

The idea of syncing Gutenberg code to core earlier in the release cycle has often been mentioned as a way to fix or at least ease the pain of this process: by merging new features into core as they are developed, it’s possible to fix any bugs identified during the process as they are caught, the new features get a little extra testing in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., and most importantly, the risk of things going wrong on the eve of major release milestones is substantially reduced, with much less stress for all involved.

So, let’s get doing this! But… why has this idea been recurrently mentioned as a good solution, and still not implemented?

The answer lies mostly in the Gutenberg development process, and its differences from the rest of core.

Iterative code

Developing features in Gutenberg often starts as a quick, messy experimental process, before stabilising into mature, tested, shippable code. And there are multiple features simultaneously in development, which means that at any given point, there is some amount of unstable code in the plugin, which is undesirable to have in core. 

The good news is that there are mechanisms already available to avoid merging unstable code into core: using the IS_GUTENBERG_PLUGIN flag means that code won’t run in core. The historical __unstable and __experimental prefixes previously used in functions are being replaced with a private APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. system that makes experimental code inaccessible to extenders.

These mechanisms are not uniformly enforced during development though, and this is where there is some room for improvement. Whereas it’s possible to measure things like code coverage, there is no good way to automate checking whether code is otherwise stable or not, so implementation is largely up to individual contributors. Here is where documentation of expectations for the development process might be useful, so folks are aware that these rules exist and why.

Package ecosystem problems

Given that core largely consumes Gutenberg code in the shape of npm packages, there are occasional hiccups due to breaking changes in dependencies that are only noticed in core. This is because the package install process pulls the latest versions of all nested dependencies that might have not yet been updated in Gutenberg. This is the sort of problem that would hugely benefit from being detected early on, so that Gutenberg code can be updated to support the breaking changes.

One thing that could help here is regenerating the package-lock file in Gutenberg and committing it back to the repo when packages are published, so that any updated dependencies can be tested as part of the plugin release process.

Fixing dependency-related breakage also needs to be prioritised, and often during the Alpha part of the cycle developers are busy building out features so it’s easy for these bugs to slip between the cracks.

One thing that could mitigate this issue is nominating the release team (or at least the editor tech part of the team) for the next release before the current release ships. The overlap would allow for handover, so the new team is aware of any pending issues that didn’t get solved during the previous cycle, and able to coordinate fixing them, or at least not be tripped up by unexpected bugs. This means there will always be someone with ownership of the process to follow up with these issues.

Release cycle timing

Another point to consider is that the core workflow of committing changes to trunk before backporting them to the release 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"., is an impediment to updating packages in trunk with the latest changes from Gutenberg until after the stable release ships. This is because the package updates for the release during Beta/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). will be committed to trunk, and those package versions have only the 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. fixes necessary for the release. 

This may not be a huge problem though, as starting the sync process only after the stable release still leaves plenty of time for testing and solving any issues.

To summarise: what needs to be done in order to successfully start syncing core and Gutenberg earlier in the release cycle?

  • On the Gutenberg side, make sure all experimental/unstable code is made private and/or put behind a feature flag;
  • On the release organisation side, have some overlap between release teams so handover is easier and ownership of ongoing issues isn’t dropped.

Further suggestions, problems, feedback and ideas are very welcome!

Thanks to @andrewserong, @ramonopoly and @mamaduka for reviewing this post and @0mirka00 and @noahtallen for the package-lock suggestion 🙂

#block-editor, #gutenberg, #release-process

Héctor Prieto 7:47 pm on March 23, 2023
Tags: , , release-process   

WordPress 6.2 Release Day Process

Preparation for WordPress 6.2 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-03-27 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 candidate).
  • 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.2.0 (i.e., in the 6.2 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.2.1.

The Release Party 📅

UPDATE: Following a regression fixed during code freeze and the restart of the code freeze clock, the release party has been rescheduled to 2023-03-29 17:00 UTC

The release party on March 28th 29th 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 5.6.20 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.2 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.1, and 6.2 RC4, 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.

Thanks to @cbringmann and @hellofromtonya for the peer review

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

Andrew Ozz 12:40 am on February 18, 2023
Tags: , release-process   

Proposal: Updates to the WordPress Release Cycle

What is Feature Freeze

In the WordPress release cycle, feature freeze happens when 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. version is released. “Feature freeze” means that development of new features and enhancements ends, and work continues on testing them and fixing bugs. They have to be ready for testing and committed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. before the freeze, before Beta 1 is released.

Exceptions to Feature Freeze

Changing tickets from “enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.” to “task” right before Beta 1 is an exception that has been used for many years. It was strictly for new features and substantial enhancements that weren’t ready in time for beta, and needed a few more days to get completed and committed (thus delaying their testing to Beta 2). The intent was to allow another two or three days, not a week or two. This exception used to happen quite rarely, perhaps a few times per year.

However lately this exception has become part of the standard release workflow. In recent years, it’s become common for 15 to 20 tickets for code coming 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 be changed to tasks each release. The reason they are changed is not to give the developers a few more days to complete them. It is mostly to signify that they are going to be committed later.

Why Gutenberg Merges Are Different

The new features and enhancements coming from Gutenberg have already been tested. I think everybody would agree that testing in Gutenberg releases is quite better and more efficient than testing in core trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. beta releases:

  • The Gutenberg plugin is used on over 300,000 sites, including some huge sites like WordPress.com.
  • According to recent stats at least 60% of these sites are rapidly updated to the newest version of the 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.

So the new features and enhancements that are in a Gutenberg release are being tested on at least 180,000 sites, and by well over 180,000 users, mostly in a production environment. For comparison, there are usually only a few thousand installs for beta releases.

It seems the WordPress release workflow should adapt to these changes in the development process: synchronizing code between two repositories, new Gutenberg releases every two weeks, etc. Using the old “change enhancements to tasks” exception shouldn’t be necessary for code that has already been released and tested in Gutenberg. However, it still makes sense for feature development that happens on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

New Ticketticket Created for both bug reports and feature development on the bug tracker. Type: Gutenberg merge

I’d like to propose to stop changing tickets from “enhancement” to “task” before beta when the code has been sufficiently tested in Gutenberg.

Based on the above plugin installation stats it seems that a sufficient time for testing in a Gutenberg release would be one week. Ideally, all code coming from Gutenberg would meet this criteria, regardless of the WordPress release cycle stage (alpha, 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).). An exception would be when committing 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. fixes that can be tested simultaneously in Gutenberg and core beta/RC releases.

To easily distinguish these tickets maybe a new ticket type can be introduced. Perhaps “Gutenberg merge” or “Gutenberg sync”? Alternatively, the existing gutenberg-merge keyword could be used, although it would be somewhat less noticeable.

For example:

A ticket with the “Gutenberg merge” ticket type
A ticket with the gutenebrg-merge keyword

Feedback

I realize that this proposal affects only a small part of the community, primarily frequent 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., committers, and release leads. But I still think it is best to propose it here in the interest of openness, and for documentation purposes.

If you have thoughts about how new Gutenberg features are handled with regard to “feature freeze” during the beta stage of the release cycle, please share them in the comments below.

Thanks @peterwilsoncc, and @ironprogrammer for the review and suggestions.

#proposal, #release-process

Héctor Prieto 12:47 am on October 25, 2022
Tags: , , release-process   

WordPress 6.1 Release Day Process

Preparation for WordPress 6.1 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:

Edit History

  • October 27th: Dry Run was rescheduled to start earlier, as proposed in #6-1-release-leads.
  • October 31st: Provided RC6 launch, 24-hour code freeze start time, and release party start time.

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 2022-10-31 14: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. This locking period started on 2022-10-31 23:29.

What does this mean? No source code for 6.1.0 (i.e., in the 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".) 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 blocker.

  • 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.1.1.

The Stable Release Party 📅

The final release will occur on 2022-11-01 23:30 in #core.

The release party on November 1st 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 different server configurations available. 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 5.6.20 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 even start this early by running the WordPress 6.1 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.37, 4.9.22, 5.8.6, 5.9.5, 6.0.3, and 6.1 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.

Props to @desrosj and @zoonini for peer review.

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

Héctor Prieto 8:04 pm on May 19, 2022
Tags: , , release-process   

WordPress 6.0 Release Day Process

LAST POST UPDATE: May 25th

Preparation for WordPress 6.0 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:

RC4 ✅

In an effort to increase the robustness and quality of the release, the release squad has agreed to launch an additional RC4 before the dry run. The WordPress 6.0 RC4 release party is scheduled on 2022-05-20 16:00 in the #core Slack channel.

Dry Run ✅

The Dry Run is a key event to determine readiness for the final release. As noted above, the current plan is to start it on 2022-05-23 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 updates are done in the src/wp-admin/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and 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 24-hour code freeze goes into effect. This locking period started on 2022-05-23 18:30.

What does this mean? No source code for 6.0.0 (i.e., in the 6.0 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 no, then the bug is targeted for 6.0.1.

The Stable Release Party ✅

The final release will occur at 18:30 UTC (link to add to your calendar and see in your local time) in #core.

As noted above, the release party on May 24th 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 there are any last-minute issues that 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 different server configurations available. 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 5.6.20 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 even start this early, by running the WordPress 6.0 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.35, 4.9.20, 5.8.4, 5.9.3, and 6.0 RC 3, as well as any other versions possible.
  • Remove 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.

Props to @annezazu and @hellofromtonya for peer review.

#6-0, #release-process

Tonya Mork 4:42 pm on January 20, 2022
Tags: , , release-process   

WordPress 5.9 Release Day Process

Updated: 24 Jan 2022

Preparation for WordPress 5.9 final release is underway. This post shares the release process, including the timeline and how you can help.

Release Timeline

The current plan is:

Dry Run

Update: The Dry Run was successfully completed ✅ See the process in the #core Slack channel.

The Dry Run is a key event to determine readiness for the final release. As noted above, the current plan is to start it on 2022-01-24 15: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 updates are done in the src/wp-admin/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and checks pass.

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

24 Hour Code Freeze

Update: The 24-hour code freeze is in effect 🕜

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

What does this mean? No source code for 5.9.0 (i.e., in the 5.9 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 no, then the bug is targeted for 5.9.1.

The Release Party 🎉

WooHoo, you’ve made it to release day 🎉!

As noted above, the current plan is to start the release party on 2022-01-25 19:20. 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 there are any last-minute issues that 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 different server configurations available. 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 5.6.20 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 even start this early, by running the WordPress 5.9 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.33, 4.9.18, 5.7.2, 5.8.3, and 5.9 RC 3, as well as any other versions possible.
  • Remove 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) installs.
  • 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.

Props to @jeffpaul for peer review and @marybaum, @webcommsat, and @cbringmann for editing.

#5-9, #release-process

Jeffrey Paul 9:51 am on July 19, 2021
Tags: , , release-process   

WordPress 5.8 Release Day Process

We’re less than 24 hours away from WordPress 5.8! If you would like to help with the final steps of the release, here is how you can join in.

The current plan is to start the release process at Tuesday, July 20, 2021 1500 UTC in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

The major version release process can take a bit more time than the Betas or Release Candidates do, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We will be working through the Major Version Release process for anyone who wants to follow along. Earlier today the pre-final release dry run was coordinated in #core (Slack archive).

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the different server configurations available. 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 5.6.20 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.

There are two ways to help test the package:

  • Use 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/ to test: wp core update https://wordpress.org/wordpress-5.8.zip
  • Directly download the 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./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). version (e.g., https://wordpress.org/wordpress-5.8.zip)

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-CLI or one-click installers.
  • Test upgrading from 4.0.33, 4.9.18, 5.7.2, and 5.8 RC 4 as well as any other versions possible
  • Remove wp-config.php file and test 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) installs
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does Multisite upgrade properly?

Finally the following user flows, on desktop and mobile, would be great to validate work 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.

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

#5-8, #release-process

Francesca Marano 10:33 am on October 29, 2020
Tags: release-process   

Discussion: align the WordPress release cycle with the industry standard

The standard software release life cycle hasn’t really changed much since the beginning of programming.

WordPress, for the most part, attempts to closely follow the established pattern, with the exception of what can get committed in 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..

For the past year, there have been conversations in Slack and in the blog about the release cycle. Here is a recap post with a call for feedback.

The WordPress Release Cycle – Today

Each release cycle spans multiple weeks and different phases.

Phase 1: Planning and securing team leads

This period starts as soon as a 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". is created for the previous version (the code is copied from “trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.” to a new “branch” in the repository), which means that two major WordPress versions are worked on at the same time. For example, active development on WordPress 5.6 started about two weeks prior to the WordPress 5.5 release. 

During this phase, the release leadRelease Lead The community member ultimately responsible for the Release. discusses features for the next release of WordPress. Contributors get involved with that discussion. The release lead will identify focus leads for each of the features. Information is gathered from different sources to put together a scope and schedule, followed by a kickoff post.

Phase 2: Development work begins

The kick-off post (see an example from WordPress 5.6) marks the beginning of structured, organised work towards Beta. The length of the period might vary, based on what was achieved during the period before the announcement and what is planned for the release.

Focus leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.

Phase 3: Beta 

Betas are released and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are allowed for the rest of the release.

WordPress generally plans for multiple betas.

Phase 4: 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).

In WordPress, release candidates are considered code complete, so no new source code is introduced unless it is to fix regressions or serious bugs discovered during 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).. Even then, every commit during this phase needs sign-off from two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers.

This means hard-freeze on all strings, including those in the About page. It is important to do so to allow the Polyglots team to have enough time to translate it.

During this phase, a new branch will be created thus starting a new release cycle while we are finishing the current.

Phase 5: Launch

This is the final version that is launched and available for update through the dashboard or via download.

How to align the WordPress release cycle with the industry standard

With this in mind, here are the changes that could be put in place to align the WordPress release cycle with the traditional software release cycle.

Phase 1: Preliminary Planning

Stays the same in terms of tasks. Can be renamed “Preliminary planning” for brevity and clarity.

Phase 2: Alpha

While traditionally priority has been given to enhancements and new features, it would be beneficial to address also all the 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.-fixes that are planned for inclusion in the version of WordPress people are working on. 

Changes

  • Rename to “Alpha” for brevity and clarity.
  • All the bugs that people want to see fixed in the next release need to be addressed in this phase and not postponed to Beta.

Phase 3: Beta

This is where WordPress differs from the standard. 

Historically, 

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.

Wikipedia

Beta is essentially for testing and fixing bugs discovered after the release of Beta 1 (so bugs introduced in Alpha).

Changes

  • Hard freeze on Beta (ETA code and strings), except for the About page.
  • The tickets that were not committed and are still on the milestone at the time of Beta 1 release party, should be moved to a later release, even if they are bugfixes.

Benefits

  • Virtually no new bugs are introduced during Beta. This means focus on testing and subsequent bug fixing. 
  • More efforts and resources could be allocated to beta-testing. 
  • Beta and RC could be and should be fewer and shorter. This is because we address only bug fixes that emerged during beta testing. 
  • Aligning to the norm makes it easier for new people to join since they are used to a certain procedure and they won’t be confused by the way releases are done in WordPress.

Phase 4: Release Candidate

No changes

Phase 5: General Release

Stays the same in terms of tasks. Can be renamed to “General Release” for clarity.

It’s your turn!

Disclaimer: even if everyone is on board, nothing will change for the current release cycle, WordPress 5.6, because we are already in Beta. 

Please post feedback on:

  1. Name changes for Phase 1, 2 and 5
  2. All bug-fixes milestoned to be addressed in Alpha and not postponed to Beta 
  3. Reserving Beta for testing and fixing bugs discovered by testing

Deadline: November 17th, the date scheduled for Release Candidate 1 of WordPress 5.6 and, potentially, when trunk gets branched for 5.7. Extended to December 2nd, to give people more time to respond.

Thanks!

Props @azaozz, @davidbaumwald, @joostdevalk and @ireneyoast for providing historical and technical knowledge on release cycle procedures, and @chanthaboune and @jeffpaul for editing suggestions.

#release-process