Release Party Chats

Every new version of the Performance Lab plugin is released during a “release party chat.” Chats are held in the #core-performance channel every third Monday of the month, which accordingly coincides with the release cadence of the 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 Plugin Directory or can be cost-based plugin from a third-party. The concrete time of the chat depends primarily on the person leading the chat and is always announced in the last weekly chat before the third Monday of the month.

The purpose of this chat is to walk through the steps necessary for preparing the release and publishing the release together. The person leading the chat typically goes through the steps in their development environment, updating the other participants on the progress and requesting feedback, reviews, and testing as outlined in the above documentation.

The first major step of releasing the plugin is branching off trunk into a new release branch. Note that this typically happens decoupled from the release party chat, in the week before. In other words, by the time the release party chat is happening, this branch (in the format release/{milestoneName}) should already exist for several days.

Running the chat

Top ↑

Preparing for the chat

Before you get started, make sure that no issues or PRs remain in the milestone for the release, with the exception of a single issue dedicated to the release process itself.

When you are leading the chat, it is advisable to prepare the initial pull request prior to the meeting so that participants do not have to wait for you to complete the steps. Preferably, you should prepare the pull request a couple minutes or hours before the chat so that the release branch is unlikely to see any further updates before the release.

  • Work through the steps in the guide for releasing the plugin:
    • Create a local branch based on the existing remote release branch release/{milestoneName}. A good practice is to name this branch publish/{milestoneName}.
    • Go through the following steps in the guide to:
      • Update the version number
      • Update the list of default enabled modules
      • Update translation strings
      • Update readme.txt
        • For this one, pay particular attention to the changelog content added to the readme for the new release to ensure that it is clear and understandable.
        • If any of the entries needs to be updated, open the corresponding pull request and update its title to a more accurate message, then re-run the readme command to have it updated in readme.txt.
        • Other contributors will later review it, so don’t worry too much if you are unsure about a changelog entry.
    • Commit the changes to your branch – either a single commit for all steps or individual commits for each of the 4 steps.
    • Push your local branch to the 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. repository and open a pull request. This would be good to do as close to the chat as possible, or even as the first task that you do during the chat (see below).
      • Set the PR to fix the issue (that should already exist) for preparing the release.
      • Make sure to add the minimum necessary labels Infrastructure, [Type] Documentation, and no milestone (since we don’t want this PR’s title to show up in a changelog).

The key here is that you should have all code for the initial pull request ready before the chat starts.

Top ↑

Facilitating the chat

When leading the chat, you should essentially walk through the steps in the releasing instructions together with the chat participants. While the chat is freeform in terms of which wording to use, the list below includes example wording most of which you can paste directly in SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at, since the procedure of the release party chat is usually the same. Having prewritten messages for the individual steps is particularly helpful because it allows you to focus mostly on the technical steps you need to take. This also reduces the time that other participants need to wait for you to perform a certain step as part of the release process.

  • At the start time, use the /here command to signal the start of the chat.
    • “/here <release-party-chat> It’s release party time for {versionNumber}! :partying_face:” (make sure to update the version number)
  • You should then remind participants about the release instructions and link to them:
    • “As always, we’re now going to work through the release steps outlined here:”
  • After that, share the release branch with the other participants, which was already created before:
    • “The release branch was already created a few days ago to allow continuous merging of other enhancements to trunk in the meantime. Here it is:{versionNumber}” (make sure to update the version number)
  • Next, open the pull request with the code that you prepared prior to the chat. Make sure to set its base branch to be the release branch, not trunk:
    • “First, I am going to open a pull request with the release preparations as outlined in”
  • You should then share the pull request URLURL A specific web address of a website or web page on the Internet, such as a website’s URL with the other participants and request a review, as two approvals are needed for it as usual:
    • “PR can be found here:{prNumber}” (make sure to update the URL)
    • “Please review :point_up: and approve if it’s good to merge. As always, most importantly focus on the readme changelog and whether that makes sense”
  • Once the PR has the two or more necessary approvals, you may still need to wait for any continuous integration tests to successfully complete first:
    • “Waiting for unit tests… :hourglass_flowing_sand:”
  • After that, you can merge the PR and provide the update to the chat.
  • The next stage is to actually publish the release. Remind the participants that nothing else should be committed to the plugin at this point:
    • “Now that the branch is ready, we’ll kick off publishing the release by creating the release tag on GitHub (see **Please don’t commit anything to the branch at this point.**
  • While the first step here is to already deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. the release to 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., keep in mind that right after that, some final smoke testing should be conducted particularly for the update process itself. In other words, sharing the update (e.g. on social media) should be discouraged until the end of the chat:
    • “Also, once the new Performance Lab plugin release is live, don’t share it right away with the wider public – first let’s do our regular testing routine of the new update’s installation / upgrade process (as described in”
  • Once you have shared the above reminders, go ahead and create the release tag. Pay attention to change the target branch so that it’s the new release branch, not trunk. The release title and tag should be the same as the milestone name (e.g. “1.6.0”). For the content/description of the release, copy the Markdown changelog content from readme.txt into the field (without the release title heading). Make sure the checkbox for “pre-release” is disabled and the checkbox for “latest release” is enabled.
  • Publish the release and share it with the chat participants. Publishing automatically kicks off the deployment process to, so you should also link to that concrete GitHub action run:
    • “Release published ({versionNumber}), GitHub action to deploy is running here:{runID}” (make sure to update the version and the second URL accordingly)
  • Once the release has been successfully deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors., the most important part of the chat is to do the final smoke testing, primarily to test the update in various scenarios. Ask the other chat participants to help and share their results in the chat. This step is typically the most free-form, as the conversation here very much depends on the testing feedback from the contributors. This step may take 10-20 minutes. You can start with something like the following, but after that just engage with the other participants, review their feedback, do your own testing etc.:
    • “Now that the release has been deployed, let’s give it a final test. Please check various ways to install or update the latest plugin version, and also test basic interactions, e.g. with the settings page or new features that were added”
    • “Please report back your findings (hopefully :white_check_mark:) here”
  • Once all testing has wrapped up, assess the outcome. Usually there are no major findings; for anything minor, open a follow up GitHub issue. If a potentially major issue is raised, discuss with the other participants whether it is critical to ship a patch release shortly after.
  • If everything looks good with the new release, it’s time to perform the final wrap-up tasks:
    • “We’re almost ready to wrap up the release  now, but first let’s merge the changes back into our main working branch trunk (see”
  • Open a pull request to merge the new release branch release/{milestoneName} back into trunk. You can conveniently do so just by using the GitHub UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., no need to do it locally (although you can, if you prefer of course). Similarly as before, make sure to add the minimum required labels Infrastructure, [Type] Documentation, and no milestone. Afterwards, share the pull request with the other contributors to get the 2 necessary approvals. All code in that PR has already been reviewed, so this is purely a formality:
    • “I’ve just opened a PR to do that:{prNumber}” (make sure to update the URL)
    • “Please approve :point_up: – it may look like a massive PR but everything in there has already been reviewed to get merged into the release branch so you can just go ahead and approve it. Feel free to skim the changes really quickly if you prefer”
  • Once it has the necessary approvals and the continuous integration checks have passed, you can merge the pull request. Remind participants that now regular commits may continue.
    • “Awesome, just merged the PR. **Committing to the plugin may now continue.**”
  • The very last step is to close the GitHub milestone for the release just published. You can do via the GitHub milestones list UI. Share this update in the chat as well:
    • “The final task is to close the milestone. Which I just did, see{milestoneID}” (make sure to update the URL)
  • Last but not least, wrap up by sharing the release with a celebratory message:
    • “And with that, it’s a wrap – **Performance Lab {versionNumber} is live!** :tada:
      Please share the {versionNumber} release with the world:
      *{versionNumber}” (make sure to update the version throughout)
    • “Feel free to now share it further :community:”
  • As you close the chat, make sure to thank everyone for their support, reviews, and testing: “Thank you all, and see you in tomorrow’s weekly chat! :wave: :thank-you: </release-party-chat>”

Last updated: