Releasing Major Versions

Alert: This page was last updated October 22, 2019. Some things may be out of date, or unclear. If you have questions, reach out to a prior release lead.

Congratulations! You’re a release lead for WordPress! The next few months of your life will be a whirlwind of excitement, frustration, and fun. Leading a WordPress release isn’t easy, but you’ll have a great time anyway.

There have been many before you, and there will be many after you. While this page might help guide you to the finish line, each release lead brings their own touch to the release. When in doubt, talk with a previous release lead and ask for direction.

Getting Started Getting Started

It’s worth reading through the Releasing Minor Versions handbook page, since many of its points apply to major version releases, too. That’s especially true as you get closer to the release date.

Once you’ve been appointed lead for a given release, here are some things you should think about or do right away:

  • Talk to leads, committers, and component maintainers. On day one, you might have no idea what your release will contain. Spend some time with each of the various WordPress leads, committers, and component maintainers to see what they have in mind. These discussions can happen over days, weeks, or even months depending on when your release is scheduled.
  • Set a schedule. A good cadence for major releases is every four months —often April, August and December—though that’s not set in stone. One of the best ways to set your schedule: pick a release date and work backwards from that date. Check out the scheduling section below for some tips!
  • Pick release deputies. You don’t have to have a release deputy, but it’s strongly encouraged. Some release leads have two or more deputies, which is perfectly fine! The trick here is to pick deputies who can augment your talents and assist throughout the cycle. Don’t enjoy writing meeting notes or running meetings? Pick a deputy who does! Not a fan of triage? There’s a community member out there who would love to help. If you’re unsure who might be interested in being a deputy, post on make/core with a call for volunteers. (Be sure to tag your post!)
  • Post a call for ideas. WordPress is built by a large community of volunteers, only some of which are committers and component maintainers. Early on in the release cycle, post on make/core asking for ideas for the release. From that post, you’ll get individual tickets and bigger feature ideas. Sorting through them all will take some time, but will give you a great list of things to investigate for your release.

On Scheduling On Scheduling

As the WordPress project grows increasingly global, it gets harder to find perfect release dates. Here are a few best-practices to keep in mind as you settle on the likely timeline:

  • Try to be firm on the release date itself, but be prepared to add betas if necessary, or adjust RC dates.
  • Check for major holidays (including religious holidays, banking holidays, national holidays, etc).
  • Check for large events that the community attends (WCUS, WCEU, etc).

Top ↑

On Roles & Responsibilities On Roles & Responsibilities

There are a number of roles and responsibilities over the course of a release. In practice, a release lead and their deputies act as project managers (and technical project managers) for the entire release cycle.

Prior to considering the responsibilities of release leads and deputies, it’s important to understand a few qualities of effective release leads:

  • An understanding of how WordPress – both the software and the community – works. WordPress, the software, is vast. No single contributor understands the entire codebase. However, release leads and deputies should have a good understanding of how WordPress works and how the core community functions. Knowing who to ask about various tickets is an important skill for leading a release!
  • A knowledge of how open source works. Open source projects run quite a bit differently than most software projects. To be a release lead or deputy, it’s expected that you have the ability to work well as a part of an open source, global, distributed project.
  • The ability to communicate well with the community. Communication is incredibly important across every part of the WordPress community, so good communication is valued and expected. The core community communicates in English, on this site and in Slack, even though many contributors speak English as a second language. As a result of the varying backgrounds in this global community, release leads and deputies should take care when communicating in official and unofficial channels. See also: Post & Comment Guidelines.

There are also a few responsibilities that release leads and deputies have over the course of a release cycle:

  • Posting agendas, running weekly developer chats, and posting chat summaries. The overall WordPress developer community should be kept informed throughout the release cycle. Not every community member can attend the weekly developer chats, so posting agendas and chat summaries is a necessity.
  • Triaging tickets and monitoring ticket reports. There are many moving pieces to a release. Release leads and deputies should keep a watchful eye on incoming trunk tickets and monitor relevant ticket reports. This includes triaging new ticket reports (especially in unowned components) to check for blocking issues.
  • Keeping the release on schedule. Deadlines are not arbitrary. WordPress releases should strive to stay on schedule and the release lead and deputies are responsible for this schedule. (See “On Scheduling,” above.) There are many aspects to maintaining the release schedule, many of which are listed as responsibilities here.
  • Running bug scrubs. Weekly bug scrubs are a useful activity that encourage contributions from all kinds of contributors. They can be successfully run by release leads, deputies, and other contributors. Component maintainers can also run bug scrubs.
  • Reviewing and responding to feature ideas. WordPress contributors and users will post feature ideas throughout the release cycle, especially on wishlist posts. While it is not the responsibility of the release lead (or deputy) to develop each feature, they should review each feature idea and see if it warrants inclusion in their release. Many of these ideas will come from feature projects, but some may be tickets that need attention.
  • Tracking down contributors for help. It is not the responsibility of the release lead to make every technical decision, or even the majority of them. The release lead should know how and when to track down and solicit contributors for assistance. The core team is large with varied availability and the release lead should have a good understanding of which contributors are the best to provide feedback and support for a variety of tickets.
  • Regularly chatting with contributors. Keeping in close contact with regular contributors helps ensure that a given WordPress release is stable and ready for the public. Chatting with contributors on a regular basis ensures that the release lead knows both the availability of contributors and any potential blocking issues, among other things.
  • Coördinating marketing efforts. There are a number of marketing efforts that need to be managed and the release lead or deputy should have an awareness of them. The About page in WordPress core, the /news/ post, and the video are all part of this effort (more below on these specific efforts). As learned on 4.7, we should avoid having videos set to autoplay simultaneously. Note that these efforts should be conducted in conjunction with the marketing team.

Expectations Expectations

Focus leads should be available for at least 5-6 hours a week to perform their tasks, with more time as milestones like Betas, Release Candidates, and General release approach. On the days of those milestones, you might need to dedicate 4-6 hours to WordPress on one day.

There are no limitations to where you come from. We are a global community, open 24/7 so you will schedule scrubs, if needed, according to your availability and potentially find a deputy to cover other timezones

Top ↑

Pre Merge Window Pre Merge Window

  • Feature projects should prepare for merge consideration in the beginning of a release cycle. 
  • Merge proposals should be created and reviewed during this time.
  • Check to see if a new bundled theme will be included in this release.

Top ↑

Merge Window Merge Window

  • Decide which feature projects (if any) should be merged.
  • If a release video is required, kick off the work on that.

Top ↑

Pre Beta 1 Pre Beta 1

  • Compile and start to publish Dev notes. Start compiling and publishing posts that inform developers of breaking changes and major developer-focused updates of the release on make/core using #dev-notes.
  • Security Checks. Ask a member of the Security team to run the private security unit test suite to make sure no regressions are introduced. If any are found, avoid discussing the details publicly, because some sites (like run trunk or beta/RCs in production. Instead, notify the Security team privately.
  • About Page. Start compiling noteworthy features in the release and identifying a designer who can contribute illustrations. Words should be complete by RC1, images can update through RC2. Some in-depth information on the About Page process is also available.
  • HelpHub Version Page. Begin compiling noteworthy updates for designers, developers, and users. The 5.2 version page can be used as an example, or reach out to the Docs Team for help.

Top ↑

Beta 1 Beta 1

The process for a beta release is well-documented on a separate handbook page.

Top ↑

Pre Release Candidate Pre Release Candidate

  • There should be no open tickets on the release milestone.
  • Publish the Field Guide on Make/Core, highlighting the developer-focused changes in the release. This should include the devnotes published before Beta. Ideally all new and modified hooks are noted in a bulleted list (see the 4.8 Field Guide as an example).
  • All Plugin Authors (in the repo) should be emailed, letting them know to test their plugins for compatibility with the release. The email should link them to the Field Guide. Contact the Plugin Team Rep to coordinate or publish the draft release email on the Plugin Review Team’s make site (sample from 5.3 here).
  • Test the Classic Editor plugin to make sure it still works well.
  • Remind the Akismet team about the release schedule, to ensure they get any pending plugin updates released before our final release.
  • The Hosts Mailing List should be notified of an updated release date for the major version.
  • An announcement should be made about the string freeze on the Polyglots P2.
  • Committers should be reminded of Release Candidate commit policy, specifically that in the RC Phase all commits have to get double sign off from committers.
  • Run the private security unit test suite.

Top ↑

Release Candidate Release Candidate

A Release Candidate version is released as the last stage of the release cycle before the major version is released. The Release Candidate means that we’re pretty sure what is in trunk is good enough for the major release, and should be thoroughly tested by the community.

  • A string freeze takes effect at the Release Candidate stage, meaning text strings in the application can no longer be changed, including the About Page text.
  • Multiple Release Candidate versions should be released (e.g. RC1, RC2) as bugs reported against it are fixed.
  • All changes to src/ at the Release Candidate stage must be reviewed by two committers. When choosing a second committer to review your patch, look for a veteran committer with extensive experience in that area of the codebase, so that the patch can receive a meaningful critique. Committers can commit to tests/ at any time.
  • Following the first release candidate a branch for the release can be created so that early work on trunk can begin.

Top ↑

It’s time to ask the Polyglots team to help translate the upcoming WordPress version. In the list below, the example release is A.B.

Top ↑

Branching Before Release Branching Before Release

At this point, once the milestone is mostly clear, a branch for the release can be created, so that early work on trunk could start. The following files need to have version numbers updated when branching:

  • src/wp-includes/version.php
  • Both NPM files: package.json and package-lock.json
  • In trunk, update the file to include the newly created branch in the list of versions receiving security updates

When branching before a release, there are two important things that need setting after branching has taken place. Ideally these should be done before any development work on trunk begins.

  • API: Set WP_CORE_DEV_BRANCH in /home/wporg/public_html/.config/versions.php to the branch, for example, 4.9. This is used in the core update check to keep Beta Tester plugin users on the branch development path (instead of pushing them into the super-alpha 5.0).
  • Translate: Update DEV_BRANCH and WORDPRESS in /home/wporg/public_html/translate/bin/ to cause GlotPress to know that the “WordPress Development” project should import strings (“originals”) from the branch rather than trunk. This is required to prevent any string changes in trunk affecting the translation files generated. This is often also set following releases for a few weeks while translation efforts continue on the latest stable version of WordPress, and trunk may have many iterations on string changes.

After branching is performed, the Test Old Branches GitHub Actions workflow needs to be updated. As an example, here is a PR that would update the workflow file after 5.8 is branched.

Top ↑

Pre Final Release Pre Final Release

This is your pre-release checklist. Do not skip it.

  • Publish a post summarizing the release process for those looking to help and/or follow along (example from 5.1).
  • Get the name of the release’s Jazz Musician (reach out to Matt or the current project director).
  • Gather the list of Noteworthy Contributors for the Credits page. Utilize this template spreadsheet (showing sample data from 5.4) to help capture those users. Ensure all Noteworthy Contributors have a photo in Gravatar.
    • This should include props from Trac, Github, and any non-code props to add manually.
    • There are sections: All Leads, Noteworthy Contributors (including Core Devs), All Contributors. Leads and Noteworthy Contributors are compiled manually — ask each focus lead to review your list.
  • The Credits API should be updated.
    • Everyone in the first Noteworthy Contributors section (named core-developers, though not limited to developers) should get a Core Team badge.
  • Make sure the tagline is synced in about.php, freedoms.php, and credits.php.
  • Make sure the About page images use CDN URLs.
  • Publish the HelpHub release page.
  • Run the private security unit test suite.
  • The announcement post should be drafted. DO NOT PUBLISH.
    • This is based on the copy from the About Page, but will also include video (if applicable) and props at the end.
    • To display the list of props in the release post, use this shortcode: [wpcredits X.Y], where X.Y is the release version. It fetches the data from the Credits API, so there is no need to generate a separate list of props for the release post anymore.
    • Make sure the post includes a thank you note for support volunteers and translators after core props (see previous major release announcements for an example).
    • Categorize post as “release”, not as “release” and “development”.
    • Update the tweet if desired.
    • Set a featured image which is used for the link preview when sharing the post.
    • Adjust the excerpt.
      • Append &embed=true to the preview URL to ensure the embed looks good.
  • Write and proof-read announcement email. This step is temporarily suspended.
  • Update the Browser support page if we end support for any browsers.

Top ↑

Dry Run Dry Run

24 hours before the release is scheduled, perform a dry run and walk through these steps:

  • Triage any bugs reported against trunk, most easily found at the top of report 40.
  • Update src/wp-admin/includes/update-core.php
  • Run npm run grunt prerelease, to ensure all tests pass, and CSS and JS files conform to standards. (this takes a while)

Top ↑

Notify Everyone Notify Everyone

  • Notify hosts that a release is coming.
  • Notify the polyglots team of string changes.
  • Notify the systems team so they can have someone available during release.

Top ↑

Release Day Release Day

You’ve made it to release day!

Top ↑

Core Core

  1. Ensure the top of report 40 is triaged, preferably clear.
  2. If applicable, make final commit to about.php, e.g. to include a release video or update final illustrations.
  3. Verify package.json is updated
  4. Verify src/wp-admin/includes/update-core.php
  5. If there is a new default theme, verify:
    1. WP_DEFAULT_THEME in src/wp-includes/default-constants.php
    2. WP_Theme::$default_themes in src/wp-includes/class-wp-theme.php
    3. Very important: WP_CORE_NEW_BUNDLED_VERSION in /home/wporg/public_html/.config/versions.php
  6. Run unit tests
  7. Run npm run grunt prerelease
  8. Update version in src/wp-includes/version.php to remove the RC identifier and changeset – eg. 5.3-src.
  9. Branch, if this has not already been done during RC:
    svn copy -m "Branch 4.4"
  10. Tag the release. From branch:
    svn copy -m "Tag 4.7"
  11. Create release packages via the form at
  12. Share in Slack: “Just a reminder: Do not tweet or share on any social media any of the links for the release. Sometimes things go wrong and packages need to be rebuilt. The release is not official until the post is published on the official news blog.”

Top ↑

  1. Check all packages are created in /home/wporg/public_html/release-archive/.
  2. Check packages are showing up at
  3. Download and unzip/untar packages. Verify they are the same. Check MD5 sums.
  4. Manually test updates.
  5. Take a final screenshot of the downloads counter.
  6. Bump versions in /home/wporg/public_html/.config/versions.php. (If you do this on your sandbox you can test update notifications before deploying.)
    • Switch WP_CORE_DEV_BRANCH back to trunk if it was set to the branch during RC.
    • Bump WP_CORE_STABLE_BRANCH if this is a major release.
    • Bump WP_CORE_NEW_BUNDLED_VERSION if there is a new default theme. Important.
    • Update wporg_get_secure_versions(), used by an API endpoint used by Google Webmasters Tools.
    • Update wporg_get_version_equivalents(), used by the plugin directory.
  7. Update the relevant credits file.
  8. Build language packs for the release by bumping versions in /home/wporg/public_html/translate/bin/
  9. api from a dotorg sandbox.
  10. wporg from a dotorg sandbox.
  11. Run the DocBlocks parser for DevHub.

Top ↑

Tell the World Tell the World

  1. (Publish the release video on WordPress.TV. DO NOT Publicize. Un-check the publicize button so the release video does not go out on Twitter/Facebook.)
  2. Publish announcement on This will auto-publish to Twitter.
    1. Update the slug to include only the name of the release jazzer, not the release number.
  3. Kick off spamattic email (needs docs). This step is temporarily suspended.
  4. Update the Codex.
    1. Finalize Version Page in the Codex.
    2. Update CurrentVersion Template with the new version.
    3. Update WordPress Versions page.
      1. Add:
        {{ ReleaseTableMajor | version = 4.4  | date = December 8, 2015 | musician = Clifford Brown | blog =  | db = 35700 }}
      2. Remove the version from the “Planned Versions” section.
    4. Update PHP Compatibility and WordPress Versions table.
    5. Update PHPUnit Compatability and WordPress Versions table.
  5. Stare at download counter and rejoice.

Top ↑

Post Release Post Release

  1. Bump the branch version to X.Y.1-alpha-$REVNUM-src and trunk to X.Y+1-alpha-$REVNUM-src along with the corresponding package.json and readme changes for both. Assuming the next release lead has commit privileges, they should be given the honors of the trunk bump.
  2. Force nightly builds. (Note: Checksums aren’t available for the nightly. WP-CLI grabs the checksums for both the installed version and the version you’re upgrading to, so it can remove old files.)
  3. In Trac, rename the trunk version to X.Y and create a new one for trunk. Complete the X.Y milestone and create new milestones for the new cycle and X.Y.1. This must be done by a Trac admin.
  4. In Security Trac, add a X.Y version. Complete the X.Y milestone and create new milestones for the new cycle and X.Y.1. This must be done by a Security Trac admin.
  5. Update various parts of the documentation:
  6. Don’t forget the polyglots team! Share the code version of the release post on the #polyglots channel so they can translate it easily. Open the release post in the editor, then go to Settings > Copy all content. Paste it as a snippet in the #polyglots channel on Slack.
  7. During the week following the release:
    • Publish a retrospective post if desired.
    • Check in with the Support Team for any notable issues.
    • Check in with the Community Team for any community feedback.
    • Kick off the next cycle with the next lead.

Congratulations! You did it!

Last updated: