Releasing Major Versions

Warning: This page is being actively rewritten. The checklist at the bottom of the page is woefully out of date. Tread carefully and ask for help from previous release leads

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

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

Once you’ve been appointed release lead for a given release, there are a number of things you should think about or do right away. Here’s a list:

  • Talk to leads, committers, and component maintainers. On day one, you might have no idea what your release will contain. Spend some time chatting with each of the 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. Generally speaking, major releases happen every four months. At the time of this writing, WordPress sets release dates in April, August, and December each year. One of the best ways to set your schedule is to pick a release date and work backwards from that date. Be mindful of major holidays. In the past, @samuelsidler has helped with scheduling.
  • Pick release deputies. Having a deputy lead for your release is not required, but is 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

[TBD Information here about how schedules are made.]

Top ↑

On Roles & Responsibilities On Roles & Responsibilities

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

Prior to considering the responsibilities of release leads and deputies, it’s important to understand a few implicit prerequisites that all effective release leads have had:

  • An understanding of how WordPress – both the software and the core community – works. WordPress, the software, is vast. No single contributor understands the entirety of the codebase. However, release leads and deputies should have a good understanding of how WordPress works and how the core community functions. If you know who to ask about a random ticket, you’re well on your way to understanding how the community works.
  • 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, its 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 in all aspects of open source development and the WordPress community values and expects good communication. The core community communicates in English, on this site and in Slack, even as 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.

Once you have a good understanding of these prerequisites, there are 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. Because not every community member can attend the weekly developer chats, posting agendas and chat summaries for each 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 ensure there are no new blocking issues for the release.
  • 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. Over the past few releases, they have been successfully run by release leads, deputies, and other contributors.
  • 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.

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.

Top ↑

Merge Window Merge Window

Decide which feature projects (if any) should be merged.

Top ↑

Pre Beta 1 Pre Beta 1

Make/Core posts should be published informing developers of breaking changes and major developer-focused updates that come with the release.

Top ↑

Beta 1 Beta 1

[TBD]

Top ↑

translate.WordPress.org translate.WordPress.org

It’s time to allow translators to translate the upcoming WordPress version. Let’s say the release is A.B.

  1. Create a A.B.x sub-project to the main WordPress project
  2. Copy the translation sets from the Development project
  3. Do the same for each Development sub-project
  4. Add mappings from GlotPress project to WordPress branch and the project name in Rosetta.
  5. Notify the polyglots team of the strings.

Top ↑

Pre Release Candidate Pre Release Candidate

  • If there are new features or major enhancements made to the admin interface, descriptive pointers should be added to let users know about them.
  • There should be no open tickets on the release milestone.
  • A Field Guide should be published on Make/Core, highlighting the developer-focused changes in the release. This should link to the posts published before Beta 1.
  • All Plugin 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 Guide. Contact the Plugin Team Rep to coordinate.
  • 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.

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 should not be changed, with the exception of About Page text.

Multiple Release Candidate versions should be released (e.g. RC1, RC2) as bugs reported against it are fixed.

All changes to code at the Release Candidate stage must be reviewed by two permanent committers, and commits can only be made by permanent committers. Guest committers can commit to unit tests at any time.

Top ↑

Pre Final Release Pre Final Release

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

  • Pick your Jazz Musician
  • The list of Contributing Developers should be decided for the Credits page. Ensure all Contributing Developers have a photo in Gravatar.
  • The Credits API should be updated.
    • There is a shortcode that uses the credits API, so there is no need to generate a list of props anymore
  • The Codex release page should be created using the Wiki Template of Release (directions are included on that page).
  • The announcement post should be drafted DO NOT PUBLISH
    • Categorize post as “release”
    • Ensure the tweet is okay.
    • Set a featured image which is used for the link preview on Twitter and Facebook.
    • Adjust the excerpt.
      • Append &embed=true to the preview URL to ensure the embed looks good.
  • Write and proof-read announcement email.
    • Ask Matt if an announcement email is planned.
  • Work a month beforehand on video.

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 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.
  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. Verify version in src/readme.html.
  7. Run unit tests
  8. Run grunt prerelease
  9. Verify version in src/wp-includes/version.php.
  10. Branch:
    svn copy https://develop.svn.wordpress.org/trunk https://develop.svn.wordpress.org/branches/4.4 -m "Branch 4.4"
  11. Create release packages via the form at mc.wordpress.org.
  12. Force nightly builds.

Top ↑

WordPress.org WordPress.org

  1. Check all packages are created in /home/wporg/public_html/release-archive/.
  2. Check packages are showing up at https://wordpress.org/download/release-archive/.
  3. Download and unzip/untar packages. Verify they are sane. Check MD5 sums.
  4. Manually test updates.
  5. Bump versions in /home/wporg/public_html/.config/versions.php. (If you do this on your sandbox you can test update notifications before deploying.)
    • Bump WP_CORE_LATEST_RELEASE.
    • 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 wp_get_secure_versions(), used by an API endpoint used by Google Webmasters Tools.
    • Update wp_get_versions(), used by the support forums and plugin directory.
    • Update wporg_get_version_equivalents(), used by the plugin directory.
  6. Update about/roadmap.php, removing the new release from the list of upcoming releases, adding the jazzer, and adding the release date.
  7. Update the relevant credits file.
  8. deploy-dotorg.sh api from a dotorg sandbox.
  9. deploy-dotorg.sh wporg from a dotorg sandbox.

Top ↑

Tell the World Tell the World

  1. Alert translators.
  2. 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.
  3. Publish announcement. This will auto-publish to Facebook and Twitter.
  4. Kick off spamattic email (needs docs).
  5. 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 = https://wordpress.org/news/2015/12/clifford/  | db = 35700 }}
      2. Remove the version from the “Planned Versions” section
  6. Stare at download counter and drink.

Top ↑

Post Release Post Release

  1. Once updates are successfully flowing, tag the release. You will likely be asked about this multiple times in the interim.
    • From branch:
      svn copy https://develop.svn.wordpress.org/branches/4.7 https://develop.svn.wordpress.org/tags/4.7 -m "Tag 4.7"
    • OR from trunk:
      svn copy https://develop.svn.wordpress.org/trunk https://develop.svn.wordpress.org/tags/4.7 -m "Tag 4.7"
  2. 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.
  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 the branch, shrinkwrap the dev dependencies with npm shrinkwrap --dev
  5. A week after the release, have a follow up meeting and kick off the next cycle with the next lead.

Congratulations! You did it!