Release Process Edit

This document is a checklist for building and releasing a new version of Gutenberg. Unless you have commit access to the WordPress.org plugin repository, it’s unlikely to be of much use to you. πŸ™‚

Writing the Release Post and Changelog Writing the Release Post and Changelog

  • Open the recently updated PRs view, and find the PR where the last version bump occurred.
  • Read through each PR since then, to determine if it needs to be included in the Release Post and/or changelog.
  • Choose a feature or two to highlight in the release post – record an animation of them in action.
  • Save the draft post on make.wordpress.org/core, for publishing after the release.

Top ↑

Bumping the Version Bumping the Version

  • Create a PR like this one, bumping the version number in gutenberg.php, package.json, and package-lock.json.
  • Check that there’s no work in progress that’s just about to land, and inform committers to hold off on merging any changes until after the release process is complete.
  • Merge the version bump PR.

Top ↑

Build the Release Build the Release

Note: The 1.x.0 notation git and svn commands should be replaced with the version number of the new release.

  • git checkout master and git pull
    (make sure your local master is up to date, you can confirm by checking gutenberg.php and noting the version bump you merged previously.)
  • Run the command npm run package-plugin from the root of project. This packages a zip file with the final builds.
  • Check the zip file looks good. Drop it in the #core-editor channel for people to test. Again, make sure if you unzip the file that the version numbers is correct.
  • Run git tag v1.x.0 from master branch (with the new version we are shipping).
  • git push --tags

Top ↑

Push the Release Push the Release

  • Have a checkout of https://wordpress.org/plugins/gutenberg/.
    First time: svn checkout https://plugins.svn.wordpress.org/gutenberg
    Subsequent times: svn up
  • Delete the contents of trunk except for the readme.txt and changelog.txt files (these files don’t exist in github, only on svn).
  • Copy all the contents of the zip file to trunk.
  • Edit readme.txt to include the changelog for the current release, replacing the previous release’s.
  • Add the changelog for the current release to changelog.txt.
  • Add new files to the SVN repo, and remove old files, in the trunk directory:
    Add new files: svn st | grep '^\?' | awk '{print $2}' | xargs svn add
    Delete old files: svn st | grep '^!' | awk '{print $2}' | xargs svn rm
  • Commit the new version to trunk:
    svn ci -m "Committing version 1.x.0"
  • Tag the new version. Change to the parent directory, and run:
    svn cp trunk tags/1.x.0
    svn ci -m "Tagging version 1.x.0."
  • Edit trunk/readme.txt to point to the new tag. The Stable version header in readme.txt should be updated to match the new release version number. After updating and committing that, the new version will be released:
    svn ci -m "Releasing version 1.x.0"

Top ↑

Post Release Post Release

  • Check that folks are able to install the new version from their Dashboard.
  • Publish the make/core post.

Tada! πŸŽ‰