Hosting Release Parties

The WordPress release cycle has several milestones. Once the release hits 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. status, release parties happen 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. These parties step through the various release tasks required to create a public release.

A more technical Handbook page about the process for Releasing Beta Versions has technical instructions for committers and Mission Control. This page exists as a guide for the host, or “emcee”, of release parties, and it omits most of the technical detail that’s not needed to facilitate the release process itself.

This page should be updated as processes are improved after receiving feedback from contributors.

Roles needed during a release party

Note: Some or all of these roles may be performed by the same contributor, depending on availability.

• A Party Host (referred to as @emcee in this document). Typically, this is one of the release coordinators. If a release coordinator is not available, an alternate from the release squad can fill in. As a last resort, the role can be filled by a trusted contributor not part of the current squad.
• A CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. (@corecommitter). This contributor will perform the “version bump” actions. The current list of core committers can be found here.
• A member of the Security Team (@securityteammember). This contributor will verify that the non-public security tests pass for the latest set of code set to be released.
• A person with Mission Control access (@mcpilot). A contributor with this level of access is needed to package the release and refresh the nightly. The list of active contributors with this access is very small, so finding a person to fill this role ahead of time is crucial.
• A member of the marketing team, or a marketing release leadRelease Lead The community member ultimately responsible for the Release. (@marketingteamember). The person in charge of drafting the release announcement post.

Top ↑

Pre-release check-in – one hour before the party starts

Before the scheduled time, check the current release leads channel (usually named #x.x-release-leads) to confirm that all relevant teams are prepared. If more time is needed and a delay is necessary, a message in the #core channel should note the reason for the delay along with an expected time that the party will start.

Top ↑

Host script based on Beta releases

The following script contains several placeholders highlighted in blue. It’s common for the @corecommitter, @securityteammember, and @missioncontrol to be the same person; adjust the script accordingly.

Steps and actions	Script for host	Who
	/here Welcome to the WordPress X.Y-Z release party. I will be your host for this event, with @corecommitter and @mcpilot acting as behind-the-scenes drivers. (Be sure to adapt this message to the actual participants, taking into account any contributor filling multiple roles). For those who haven’t attended a release party before, welcome! Here’s the step-by-step guide from the handbook that details the release process: https://make.wordpress.org/core/handbook/about/release-cycle/releasing-beta-versions/
Step 1: Ensure the announcement post for the blogblog (versus network, site) is ready	Let’s start by ensuring the release post is ready to be published. @marketingteammember, what’s the status of the post? A public preview should be made available so anyone wanting to help proofread the post can do so. Just double-check the @props to credit them.	Marketing Leads
Step 2: Announce in Core to pause commits and don’t share links to the package until tested	@committers. Please refrain from committing until X.Y-Z has been released. :thank-you: :siren: Please remember not to 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/. :siren:	All attendees
Step 3: Run all unit tests locally	Time to run all unit tests. @corecommitter, please confirm.	Core Committer
Step 4: Verify that the latest GitHub Action checks are passing.	@corecommitter, can you also confirm that 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?	Core Committer
Step 5: Ask a Security team member to verify the private security unit tests are passing for the most recent commit to ensure no regressions are introduced.	@securityteammember, please verify the private security unit tests pass for the latest commit. Thanks!	Security Team Member
Step 6: Bump version	@corecommitter, will you please commit the first version bump? [Wait for the commit to appear]	Core Committer
Step 7: Build the packages.	@mcpilot please proceed to package the release and post the link to the package here.	Core Committer
Step 8: Package Reminder	[While the package is being built, once again, remind attendees not to publicly share the link to the package until it’s been tested and the release post has been published. Sometimes, errors can happen during packaging, and the package needs to be rebuilt.] :siren: Please remember not to share links to the package publicly until the “all clear” is given after testing and the announcement post is published on WordPress.org. :siren: [Wait until the link to the *.zip file is posted]	Emcee
Step 8: Testing	It’s testing time! There are several ways to test, so pick whatever feels most comfortable and report back as you go: 1. 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. Select the Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. channel and then 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). Only stream. 2. 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 –version=X.Y-Z 3. Directly download the Beta/RC version from https://wordpress.org/wordpress-X.Y-Z.zip Here are a few scenarios to test: – Test from latest in 4.0.* release series (e.g., 4.0.35 > X.Y-Z) – Test from latest in 4.9.* release series (e.g., 4.9.21 > X.Y-Z) – Test from the latest version in the 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., 6.1.1 > X.Y-Z) – Test from the most recent Beta/RC release (e.g., Beta 4 > X.Y-Z) – Test fresh installation – Remove wp-config.php file and test a fresh installation – 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 You can report back by sharing how you tested and what the result was with an emoji. For example: – 6.2-beta1 > X.Y-Z via beta tester If it works, add :white_check_mark: If any issues happen, add :red_circle: so we can investigate. Please note that language packs are built in a later step of the process, so it is normal for there to be notices such as Warning: Checksums not available for WordPress 6.3.2/fr_FR. Please cleanup files manually.	Everyone
Optional: Summarize any issues found	[If any issues are found during testing, rely on this section.] Thanks, everyone, for testing! For now, we’re tracking the following issues:	Emcee
Step 9: Second version bump	Please, @corecommitter, proceed with the second version bump. [Wait for the commit to appear]	Core Committer
Step 10: Rebuild the Nightly Package in Mission Control	@mcpilot, can you please refresh the nightly build? [Wait for confirmation]	Mission Control
Step 11: Publish the announcement post	The release post can now be published! @marketingteammember, please proceed.	Marketing Team Member
Step 12: Announce in #core that the release is available	/here WordPress X.Y-Z is now available: insert link from the announcement post Please help test and give feedback!	Emcee
Step 13: Announce that committers is open again	@committers, you can now resume committing. If this is a 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). release, also remind committers that the dev-feedback and dev-reviewed workflow is required for all commits to the X.X 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"..	Emcee
Step 14: Outro	The party is over! Props to @corecommitter, @securityteammember, @mcpilot for helping with the various release tasks. Thanks, everyone, for joining in and helping make WordPress! Hope to see you at future release parties.  </x.x-release-party>	Emcee
Step 15: Props	Write a message in the #props channel thanking and giving props to everyone who tested or helped with the release process.	Emcee

Share reminders

Before we go, here are a few reminders: 

• Here’s a post that covers all you need to know ahead of release day: https://make.wordpress.org/core/2022/10/25/wordpress-6-0-release-day-process-2/ (An example from WP 6.0 that can be adapted to the current release.)
• The dry run before the 24-hour code freeze is planned for date (insert date for one day before public release date)
• The public release is planned for (insert the current cycle release date). The exact time will be announced after the Dry Run finishes. You’re invited back for the biggest event of this release season!
• According to the Bug Scrub Schedule (insert a link to pinned post in Make/Core), the remaining 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. scrubs before the stable release party are as follows:
  • List dates

Last updated: November 9, 2023