The WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem. We build and manage the Performance Lab plugin, a collection of performance-related “feature projects” for WordPress core.
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 pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ 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.
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.
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 SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., 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: https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/”
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: https://github.com/WordPress/performance/tree/release/{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 https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/#preparing-the-release”
You should then share the pull request URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org with the other participants and request a review, as two approvals are needed for it as usual:
“PR can be found here: https://github.com/WordPress/performance/pull/{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 https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/#publishing-the-release). **Please don’t commit anything to the branch at this point.**
While the first step here is to already deployDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. the release to wordpress.orgWordPress.orgThe 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. https://wordpress.org/, 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 https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/#review-and-test-the-deployment)”
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 wordpress.org, so you should also link to that concrete GitHubGitHubGitHub 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. https://github.com/ action run:
“Release published (https://github.com/WordPress/performance/releases/tag/{versionNumber}), GitHub action to deploy is running here: https://github.com/WordPress/performance/actions/runs/{runID}” (make sure to update the version and the second URL accordingly)
Once the release has been successfully deployedDeployLaunching 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 https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/#update-trunk)”
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 UIUIUI 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: https://github.com/WordPress/performance/pull/{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 https://github.com/WordPress/performance/milestone/{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: * https://wordpress.org/plugins/performance-lab/ * https://github.com/WordPress/performance/releases/tag/{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>”