Releasing Major Versions

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 leadRelease Lead The community member ultimately responsible for the Release. 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

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 backward 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 triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.? 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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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 will 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.

Top ↑

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 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). 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

There are a number of roles and responsibilities over the course of a release. In practice, if there’s not a release coordinator for a cycle, a release lead and their deputies act as project managers (and technical project managers) for the entire release cycle. Otherwise, a release coordinator takes on ensuring the various pieces are properly covered by the cohesive release squad.

Important note: Much of the tasks listed in this handbook page are done by those who act as “mission control” or MC. These are a very specific set of folks with a particular ability to perform larger metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-tasks for the project. If you’re not sure how to do something or don’t have access, it’s likely a task for those folks to handle. 

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. community functions. Knowing who to ask about various tickets is an important skill for leading a release!
  • Knowledge of how open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. 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 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/., 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 ticketticket Created for both bug reports and feature development on the bug tracker. reports. There are many moving pieces to a release. Release leads and deputies should keep a watchful eye on incoming 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. 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 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. Weekly bug scrubs are a useful activity that encourages 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.
  • Coordinating 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 and the relevant component maintainers. Reference this release cycle marketing and communications guide for an in-depth handbook on release communications.
  • Communicating any changes to the release or to features. As releases proceed, there are times when big decisions need to be made and communicated appropriately by the release squad. This requires both coming together to find a way forward, sometimes involving project leadership, and doing the work to appropriately communicate any changes. Here are two examples in case the release squad you are a part of runs into similar situations: Announcing a revised release schedule for WordPress 5.9 and Webfonts API changes for WordPress 6.0

Top ↑

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 in 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 time zones.

Top ↑

Helpful Hints

  • Create a public slack channel for communication and perform weekly updates starting 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. This helps both the release squad work out in the open for the benefit of future contributors and allows folks to follow along as they see fit. The #meta team can help facilitate this. 
  • Ensure redundancy in the release squad and during release parties. With the size of the project, it goes a long way to have multiple folks in key roles and to ensure that, during release parties, there are multiple folks who can accomplish tasks. For example, having multiple MCs helps ensure someone is available in case the pre-arranged MC has a late arising conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. and cannot participate. 
  • Examine what folks have done for the last release. Because this is an open source project, much of what you need to do can be learned by looking at those who came before you. Search slack for release parties, ask questions of prior release leads, look on Make for how prior decisions were handled, etc. 
  • Recognize each part of the cycle has different restrictions and focuses. As the release cycle goes on, the focus shifts and it’s important to shift with it. For example, RC requires double sign-off for Core commits so it’s important to plan any important work with that variable in mind. 
  • Create release party scripts and get alignment well before release days. It’s normal for there to be plenty of coordination ahead of time, including creating scripts for release parties, checking with folks to ensure they can take on specific steps, etc. Handle the necessary and known stressors so that when unexpected stressors come up you have more capacity to respond. 
  • Share early and often, especially if you have concerns. While something might feel obvious to you, it can easily be overlooked by the group if not expressed. 

Top ↑

Pre Merge Window

  • Feature projects should prepare for merge consideration at 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

  • 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

Top ↑

Beta 1

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

Top ↑

Pre Release Candidate

  • There should be no open tickets on the release milestone.
  • The process for publishing the Field Guide is documented on a separate handbook page.
  • All 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 Authors (in the wp.org repo) should be emailed, letting them know to test their plugins for compatibility with the release. The email should link them to the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.. 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.
    • Akismet is automatically checked for updates, and updated if required, on every WordPress commit
    • The plugin is updated in trunk , the current stable 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". and the current development branch (if it differs from trunk).
  • The Hosting community should be notified of an updated release date for the major version. Post a Slack message in the #hosting Slack channel as a reminder.
  • An announcement should be made about the string freeze on the Polyglots P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. (example from 5.9).
  • Committers should be given a proactive reminder that the Release Candidate commit policy is coming up when RC 1 is released, specifically that in the RC Phase all commits have to get double sign-off from committers. This begins after RC1 is released so, in the reminder, alert folks that the RC phase is coming up but has not yet begun.
  • 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.

Top ↑

Release Candidate

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). version is released as the last stage of the release cycle before the major version is released. The Release Candidate means that  the release squad feels confident that what is in trunk is good enough for the 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., and should be thoroughly tested by the community.

  • A hard 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.
  • Alert committers that all changes to src/ at the Release Candidate stage must be reviewed by two committers. When choosing a second 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. to review your patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., 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.
  • The process for an RC release is well-documented on a separate handbook page.
  • Following the first release candidate a branch for the release can be created so that early work on trunk can begin for the next release.
  • An announcement should be made on Make Core about the release candidate 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.
  • At this point, two Make Core posts should be published to begin gathering nominations for folks interested and able to (1) participate in the Minor 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. Squad that follows this major release cycle and to (2) participate in the Major Release Square that’s up next.

Top ↑

translate.WordPress.org

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

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. Note: the package-lock.json file must not be edited manually. Change the version specified in package.json and run npm install to update the lock file.

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.

  • 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.: 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 in /home/wporg/public_html/translate/bin/update-originals-wp.sh 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.
  • Translate: Update /home/wporg/public_html/translate/bin/update-all-core-packs.sh to use the branch for beta/RC packages.
  • Translate: Update /home/rosetta/public_html/wp-content/mu-plugins/rosetta/rosetta.php to use the branch for the wp/dev project.

After branching is performed, there are a few additional tasks that need to take place:

  • In trunk, update the SECURITY.md file to include the newly created branch in the list of versions receiving security updates.
  • The Test Old Branches 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/ Actions workflow needs to be updated. As an example, here is a PR that would update the workflow file after 5.8 is branched. The needed changes should only be applied to trunk. This workflow only runs within the primary branch, so the newly created branch does not need to be updated.
  • The .env file in the new branch should be updated.
    • Change the LOCAL_PHP value from latest to the highest version of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher supported in that release. This helps avoid test failures in the future when the PHP version associated with the latest Docker container is changed.

Top ↑

Pre Final Release

This is your pre-release checklist. Do not skip it. To help with coordination, it’s recommended to duplicate this sheet and begin assigning tasks amongst the release squad, along with wider contributors who tend to step in during this part of the release cycle.

  • 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 GravatarGravatar Is an acronym for Globally Recognized Avatar. It is the avatar system managed by WordPress.com, and used within the WordPress software. https://gravatar.com/..
    • This should include props from TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., 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.
    • Ensure that Design leads in the release check for any missing designers as they may have been missed on code props.
  • 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 and any filler images are properly replaced with the final version.
  • 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 shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site.: [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 as this will display automatically once the Credits API is updated for the release.
    • 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 like 5.6).
    • Categorize post as “release” only, not as “release” and “development”.
    • Update the tweet if desired, including the hashtag #WordPress.
    • Set a featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. which is used for the link preview when sharing the post. Ensure that previews on Twitter, Facebook, etc. do not crop of significant portions of the image. If need be, you can clear the cache on Facebook using https://developers.facebook.com/tools/debug/ and on Twitter using https://cards-dev.twitter.com/validator.
    • Adjust the excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox..
      • Append &embed=true to the preview URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to ensure the embed looks good.
  • Update the Browser support page if we end support for any browsers.

Top ↑

Dry Run

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

Top ↑

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. If you aren’t sure how best to do this, ask your release squad if anyone is a part of this team.

Top ↑

Release Day

You’ve made it to release day!

Top ↑

Core

  1. Ensure the top of report 40 is triaged, preferably clear.
  2. Alert committers about the release and to pause committing:
    1. Example: @committers Please refrain from committing until we get 5.8 released.
  3. If applicable, make the final commit to about.php, e.g. to include a release video or update final illustrations.
  4. Verify package.json is updated.
  5. Verify src/wp-admin/includes/update-core.php.
  6. 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
  7. Run unit tests.
  8. Run npm run grunt prerelease. This will also run the unit tests. Check for result of GitHub Actions (e.g., https://github.com/WordPress/wordpress-develop/actions?query=branch%3A5.8).
  9. Update version in src/wp-includes/version.php to remove the RC identifier and changeset – eg. 5.3-src.
  10. Tag the release. From branch:
    svn copy https://develop.svn.wordpress.org/branches/4.7 https://develop.svn.wordpress.org/tags/4.7 -m "Tag 4.7"
    If this command line fails, then attempt the same tag via a GUI interface such as TortoiseSVN.
  11. Create release packages via the form at mc.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/.
  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 blogblog (versus network, site).”

Top ↑

WordPress.org

  1. Check packages are showing up at https://wordpress.org/download/releases/.
  2. Download and unzip/untar packages. Verify they are the same. Check MD5 sums.
  3. Test the packages:
    1. There are two ways to help test the package:
      1. 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
      2. Directly download the Beta/RC version (e.g., https://wordpress.org/wordpress-5.8.zip)
    2. In particular, testing the following types of installs and updates would be much appreciated:
      1. Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLI or one-click installers.
      2. Test upgrading from 4.0.33, 4.9.18, 5.7.2, and 5.8 RC 4 as well as any other versions possible.
      3. Remove wp-config.php file and test fresh install.
      4. 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.
      5. Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
      6. Does Multisite upgrade properly?
    3. Finally the following user flows, on desktop and mobile, would be great to validate work as expected:
      1. Publish a post, including a variety of different blocks.
      2. Comment on the post.
      3. Install a new plugin/theme, or upgrade an existing one.
      4. Change the site language.
      5. If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.
  4. Take a final screenshot of the downloads counter.
  5. Bump versions in .config/versions.php. (Do this on a WordPress.org sandbox so you can test update notifications before deployingDeploy Launching code from a local development environment to the production web server, so that it's available to visitors..)
    • 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_LATEST_RELEASE.
    • Bump WP_CORE_NEW_BUNDLED_VERSION if there is a new default theme. Important.
    • Update wporg_get_secure_versions() with the previous secure stable release, used by an API endpoint used by Google Webmasters Tools.
    • Update wporg_get_version_equivalents() if required, used by the plugin directory.
    • Automatic updates will commence once these changes are deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. – See the final step #9.
  6. Update the relevant credits file, and deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. the changes.
  7. Build language packs for the release by bumping versions in translate/bin/update-all-core-packs.sh.
  8. Deploy WordPress.org, deploy-dotorg.sh wporg from a sandbox.

Top ↑

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 wordpress.org/news. This will auto-publish to Twitter.
    1. Update the slug to include only the name of the release jazzer, not the release number.
  3. Publish the HelpHub release page.
  4. Update the Codex.
    1. Finalize Version Page in the Codex.
      1. Add:
        {{#dotorgredirect:https://wordpress.org/support/wordpress-version/version-6-2/}
    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 = https://wordpress.org/news/2015/12/clifford/  | db = 35700 }}
      2. Remove the version from the “Planned Versions” section.
    4. Update PHP Compatibility and WordPress Versions table.
    5. Update PHPUnit Compatibility and WordPress Versions table.
  5. Stare at download counter and rejoice.

Top ↑

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 package-lock.json changes for both. Assuming the next release lead has commit privileges, they should be given the honors of the trunk bump. Example commit from the 6.3 release: https://core.trac.wordpress.org/changeset/55611.
  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 adminadmin (and super admin).
  4. In Trac, if there is an unreleased minor milestone for the previous major, update the milestone to the new X.Y (for tickets already resolved and included in the X.Y branch) or X.Y.1 (for tickets that still need investigation or discussion). A Trac admin should then remove the unreleased minor milestone.
  5. Update various parts of the documentation:
  6. Don’t forget the polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/.! 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. Identify folks who helped with significant testing during the release process and submit them for additions to the Credits API if they were not already credited in the release. This can be done via a Meta Trac ticket.
  8. 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!

#core

Last updated: