WordPress-Coding-Standards/.github/release-checklist.md

Template to use for release PRs from develop to main

⚠️ DO NOT MERGE (YET) ⚠️

Please do add approvals if you agree as otherwise we won't be able to release.

PR for tracking changes for the x.x.x release. Target release date: DOW MONTH DAY YEAR.

Release checklist

General

• Verify, and if necessary, update the allowed version ranges for various dependencies in the composer.json - PR #xxx
• PHPCS: check if there have been releases since the last WordPressCS release and check through the changelog to see if there is anything WordPressCS could take advantage of - PR #xxx
• PHPCSUtils: check if there have been releases since the last WordPressCS release and update WordPressCS code to take advantage of any new utilities - PR #xxx
• PHPCSExtra: check if there have been releases since the last WordPressCS release and check through the changelog to see if there is anything WordPressCS could take advantage of - PR #xxx
• Check if the minimum WP version property needs updating in MinimumWPVersionTrait::$default_minimum_wp_version and if so, action it - PR #xxx
• Check if the minimum_wp_version and testVersion properties in phpcs.xml.dist.sample need updating and if so, action it - PR #xxx
• Check if any of the list based sniffs need updating and if so, action it. ✏️ Make sure the "last updated" annotation in the docblocks for these lists has also been updated! List based sniffs:
  • WordPress.WP.ClassNameCase - PR #xxx
  • WordPress.WP.DeprecatedClasses - PR #xxx
  • WordPress.WP.DeprecatedFunctions - PR #xxx
  • WordPress.WP.DeprecatedParameters - PR #xxx
  • WordPress.WP.DeprecatedParameterValues - PR #xxx
• Check if any of the other lists containing information about WP Core need updating and if so, action it.
  • $allowed_core_constants in WordPress.NamingConventions.PrefixAllGlobals - PR #xxx
  • $pluggable_functions in WordPress.NamingConventions.PrefixAllGlobals - PR #xxx
  • $pluggable_classes in WordPress.NamingConventions.PrefixAllGlobals - PR #xxx
  • $target_functions in WordPress.Security.PluginMenuSlug - PR #xxx
  • $reserved_names in WordPress.NamingConventions.ValidPostTypeSlug - PR #xxx
  • $wp_time_constants in WordPress.WP.CronInterval - PR #xxx
  • $known_test_classes in IsUnitTestTrait - PR #xxx
  • ...etc...
• Verify there has been no vandalism on the wiki (and if so, remove/fix it).

Release prep

• Double-check that all PRs which were merged since the last release have a milestone attached to it.
• Add changelog for the release - PR #xxx ✏️ Remember to add a release link at the bottom!
• Update README (if applicable) - PR #xxx
• Update wiki (new customizable properties etc.) (if applicable)

Release

• Merge this PR.
• Make sure all CI builds are green.
• Tag and create a release against main (careful, GH defaults to develop!) & copy & paste the changelog to it.
  ✏️ Check if anything from the link collection at the bottom of the changelog needs to be copied in!
  • Remove square brackets from all ticket links or make them proper full links (as GH markdown parser doesn't parse these correctly).
  • Change all contributor links to full inline links (as GH markdown parser on the Releases page doesn't parse these correctly).
• Make sure all CI builds are green.
• Close the milestone.
• Open a new milestone for the next release.
• If any open PRs/issues which were milestoned for this release did not make it into the release, update their milestone.
• Fast-forward develop to be equal to main.

After release

• Open a Trac ticket for WordPress Core to update.

Publicize

• [Major releases only] Publish post about the release on Make WordPress.
• Tweet, toot, etc about the release from your personal account (there is no official WPCS account).
• Post about it in #core channel on the WordPress.org Slack.
  ✏️ No need to post in the #core-coding-standard channel as that gets an automated release notification anyway.
  • Optionally post in #plugin-review if a sniff was added in a release which was requested by the plugin review team.
  • Optionally post in #core-docs if significant updates were made to the documentation ruleset.
• Create a Marketing team "amplify request".
• Submit for the "Monthly Dev Roundup".