Releasing Beta Versions

This is an initial outline of steps to take when releasing a beta version of WordPress. As you go through this process, please add to the steps below so future contributors have an easier experience.

  • Open Releasing Minor Versions handbook page
  • 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).
  • Announce in #core so nobody tries to commit
    • @committers Please refrain from committing until we get 4.8-beta2 released. (archive)
    • Share message in #core-committers
  • Verify latest Travis is clean
  • If doing a minor release, check out the release branch: svn switch '^/branches/4.7'
  • Run all unit tests locally:
    • phpunit --stop-on-failure
    • phpunit --group ajax --stop-on-failure
    • phpunit -c tests/phpunit/multisite.xml --stop-on-failure
  • Bump version.
    • 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.
    • Update $wp_version to add the appropriate version identifier and remove the SVN changeset number:
  • 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.)
    • https://mc.wordpress.org/release/
    • Enter build name?
    • Click button?
  • test them
  • announce in #core that release is available
  • publish the announcement post
    • Notify Matt (is this Matt’s job?)
  • 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/
  • Announce to @committers that SVN committing in #core is open. If an RC release, note the dev-feedback and dev-reviewed workflow is required prior to committing, where each commit must get double-signoff.
  • Write message in #core thanking and giving props to everyone who tested, and share this message into the #props channel.
  • If this is the 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.