Releasing Beta and RC Versions

These are the prescribed steps to take when 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. version of WordPress. As you go through this process, please add any missing information to the steps below so future contributors have an easier experience.

• Draft the announcement post.
  • Copy a previous wordpress.org/news/ post and start editing from there (e.g., Beta 1, Beta 2, RC 1, RC 2).
  • When drafting the post, ensure you check the “Enable public preview” option in the “Status & visibility” sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. panel so you can copy and share that preview URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org with others to help review and provide feedback before publishing.
  • Ensure links, ticketticket Created for both bug reports and feature development on the bug tracker. counts, and other aspects are updated for your specific beta release. For TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. query links, ensure any dates in the URL are in the YYYY-MM-DD format for cross-localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. compatibility.
  • Obtain reviews for accuracy from release leads and copyediting from marketing or documentation folks. Ensure these folks get @mentioned at the end of the post.
  • Note that if this 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). release was originally unplanned (e.g., an additional Beta before RC, an additional RC before final release), then historically these announcement posts as “silent” in that they are not published on wordpress.org/news/ and instead on make.wordpress.org/core (e.g., 5.7 RC 3 or 6.2 Beta 5).
• For Beta 1 releases, it is strongly recommended to coordinate with the FSE Outreach Experiment folks in #fse-outreach-experiment to publish and promote a “Help Test WordPress X.Y” post (e.g., 6.1 post, 6.1 Slack message).
• For Beta releases, ensure that the milestone is cleared of enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. and feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. tickets (e.g., Trac query for 6.1). If there is agreement within the release squad that a certain enhancement or feature request is critical for the release and thus needs to remain in the milestone, its ticket type should be changed to “Task (blessed)”. Also ensure with the Editor Tech Lead that enhancements/features merges 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/ are similarly either cleared from the milestone or changed to a “Task (blessed)”.
• For RC releases, ensure that the milestone is cleared of all tickets or otherwise have agreement within the release squad as to why any remain (e.g., Trac query for 6.1). Also ensure with the Editor Tech Lead that all merges from Gutenberg are also cleared from the milestone.
• Before starting, run all unit tests locally.
  • Ensure NPM packages are updated locally to reflect the latest changes before running these tests
  • phpunit --stop-on-failure
  • phpunit --group ajax --stop-on-failure
  • phpunit -c tests/phpunit/multisite.xml --stop-on-failure
• For Minor releases, verify that all closed tickets in the milestone have had their commits merged into the release (looking for tickets that lack fixed-major can narrow this down). Minor releases may optionally include beta releases. The decision is at the discretion of the release leadRelease Lead The community member ultimately responsible for the Release..
• Announce in #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. so nobody tries to commit.
  • Example (archive): @committers Please refrain from committing until we get 4.8-beta2 released.
• Remind those attending the release party to not share links to the release package until after it’s been tested.
  • Example (archive): Reminder: Please do not share links to the package publicly until the all-clear is given after testing and the announcement post is published on 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/.
• Remind those attending the release party to refrain from non-relevant chatting.
  • Example: Reminder: Please refrain from non-relevant chatting.  This is an important process, and a lower signal-to-noise ratio isn’t helpful if something goes wrong.
• Verify latest GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Action checks are passing (i.e., all show ✅).
  • Check the latest commit on https://github.com/WordPress/wordpress-develop/actions?query=event%3Apush+branch%3Atrunk
• For Minor releases, check out 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".: svn switch '^/branches/4.7' and remind people to update their current install or make a fresh install.
• Ask a member of the Security team to run the private security unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite to make sure no regressions are introduced.
  • If any are found, avoid discussing the details publicly, because some sites (like wordpress.org) run trunk or beta/RCs in production. Instead, notify the Security team privately.
• Bump version.
  • Update the $wp_version in trunk/src/wp-includes/version.php (e.g., $wp_version = ‘5.8-beta1-src’;).
  • Update the version in the package.json if it hasn’t been updated yet.
  • If the $wp_version is 4.8.1-beta1 then the version in package.json should be just 4.8.1.
  • If you are releasing an RC, then the $wp_version would be 4.8.1-RC1-src.
  • Update $wp_version to add the appropriate version identifier and remove the SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. changeset number:
  • Ensure version bump appears on https://build.trac.wordpress.org/. This only needs to be verified by the person releasing via Mission Control.
• Build the packages.
  • The release package needs to be built in Mission Control. Once it’s packaged, it needs to be tested well, including manually testing updates. (How do you do that? Checkout the docs.)
  • Enter build name?
  • Click button?
• Test the packages.
  • Ask people to test by sharing the URL (e.g., https://wordpress.org/wordpress-4.9-beta2.zip).
  • There are three ways to help test the package:
    • Install and activate the WordPress Beta Tester 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
      • For major RC releases, select the Bleeding edge channel and then Beta/RC Only stream.
      • For a minor RC release, select the Point ReleaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. channel and the Nightlies stream (note that it is no longer possible to use beta tester to test the minor Beta/RC packages until after the nightlies have been built).
    • 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-4.9-beta2.zip
    • Directly download the Beta/RC version (e.g., https://wordpress.org/wordpress-5.8-RC4.zip)
  • Note: If anyone reports files removed when updating via WP-CLI, make sure you verify that those files exist in the $_old_files variable.
  • Note: Folks testing packages using the WP-CLI may report warnings related to checksums. This is expected because checksums are not available for nightlies.
  • Ideal tests to run:
    • Test from latest in 4.0.* release series (e.g., 4.0.35 > 6.1 Beta 1)
    • Test from latest in 4.9.* release series (e.g., 4.9.21 > 6.1 Beta 1)
    • Test from latest in current 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. series (e.g., 5.7.2 > 5.8 Beta 2)
    • Test from most recent Beta/RC release (e.g., Beta 2 > Beta 3, Beta 3 > RC 1, RC 1 > RC 2)
    • Test fresh install
    • 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
• Another version bump.
  • Commit: Post WordPress 4.8 Beta 2 version bump.
• The nightly package now needs to be rebuilt in Mission Control after the previous commit appears at https://build.trac.wordpress.org/
• Publish the announcement post (and the subsequent “Help Test WordPress X.Y” post if this is the Beta 1 release and a post was created).
  • Matt can do this, or anyone with Adminadmin (and super admin) or Editor access to wordpress.org/news/.
  • Share the post content in the #polyglots channel to help them generate translated versions (e.g., Slack message for 6.1 Beta 1 sharing the code editor content).
• Announce in #core that release is available.
  • Example: /here WordPress 5.8 Beta 1 is now available. Please help test! There’s a lot to test this release.
  • As a reminder, only tickets related to functionality added in 5.8, test changes, and documentation updates will be considered during beta this release.
• Announce to Committers that SVN committing in #core is open.
  • Example: @committers Feel free to resume committing.
  • For RC releases, note the dev-feedback and dev-reviewed workflow is required prior to committing, where each commit must get double-signoff.
    • Example: @committers Feel free to resume committing. Reminder that we are now in the RC period so all commits will require double-signoff using the dev-feedback and dev-reviewed Trac keywords on each ticket.
• Write a message in the #props channel thanking and giving props to everyone who tested or otherwise helped with the beta release process
  • Example: Props to @mention, @mention2, …, @mentionN for helping test today’s 5.8 Beta 1 release!
• For a major Beta/RC release, update the Make/Core page for the cycle with details for the release, including links to the release post, 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/. Archive, and the Zip Download. Example: https://make.wordpress.org/core/6-4/.
• For first Beta in the release cycle:
  • Add a new Milestone to Core Trac for the next release version. For example, when releasing WordPress 5.0, add a Milestone for 5.1. You may need to ask someone with admin rights on Trac to do this.
  • A member of the Security team should email participants in our HackerOne program, encouraging them to find any new vulnerabilities before they make it into the stable release. See the Security Team handbook for details.
• For first RC in the release cycle:
  • An announcement should be made on Make Core about the 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). phase (example from 6.0) and the various above protocols in order to better amplify this specific part of the release cycle and prepare the community.

Last updated: March 11, 2024