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.
This article describes how to publish a new release of the Performance Lab 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 WordPress Performance Team is currently revising the process for releasing Performance Lab and its standalone plugins. As such, it is expected that some of the steps outlined in this article may change in the future.
The cutoff point for a release specifies the point in time where no new features or enhancements should go into the release, only critical fixes. There is no hard rule for when this point should be reached, but the loose guidance is around a week before the tentative release date.
At the cutoff time, create a new remote branch release/{versionNumber} from latest trunk, where {versionNumber} is the release version. For example, if the version number is 1.2.0, name the branch release/1.2.0.
Once the release branch exists, any pull requests that are relevant for that upcoming release need to be based on the release branch instead of trunk. For relevant pull requests that are already in progress at the time of creating the branch, change the base branch accordingly.
Most importantly, immediately communicate with the other plugin contributors that the release branch now exists, e.g. by updating the overall release issue with a new comment or leaving a note in the #core-performance Slack channel. This way other contributors should be aware that critical pull requests related to that upcoming release need to be based on the release branch instead of trunk.
Before making any changes, create a new local branch based on the remote release branch release/{versionNumber}. Make the following changes in that local branch.
The version number needs to be manually updated in the following places:
in the plugin headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. in load.php
in the PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. constant in load.php
in the readme header in readme.txt
In addition to those locations, run the npm run since -- -r {version} command to replace any occurrence of @since n.e.x.t with the version number. This ensures any code annotated with the “next” release will now have its proper version number on it. The only exception to this are pre-releases, such as a betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. or RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.: For those, the stable version number should be used. For example, if the milestone is 1.2.0-beta.2, the version in e.g. @since annotations in the codebase should still be 1.2.0.
Run npm run readme -- -m "{milestoneName}" to update the readme.txt file with the release changelog, where {milestoneName} is the name of the milestone. For example, if the milestone is performance-lab 3.0.0, the command needs to be npm run readme -- -m "performance-lab 3.0.0".
After running the command, check the readme.txt file to ensure the new changelog for the release has been added. Also review its changelog entries for whether they make sense and are understandable. Make sure that no unexpected changelog entries are present.
As the eventual Performance Lab release will also publish any pending standalone plugin updates managed through the WordPress/performance GitHub repository, it is crucial to ensure that the code for any plugins that meet those requirements is in fact ready to be released in the release branch before tagging the new Performance Lab release.
Please ensure that any plugins with pending version updates are ready to be published, per the requirements outlined in the article for releasing standalone plugins.
Push your local branch to the 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/ repository and open a pull request against the release branch release/{versionNumber}. As usual, make sure to request a review from at least 2 plugin maintainers. Once approved, the pull request can be merged.
Once the above pull request has been merged, let the other maintainers know on Slack that no new commits or pull requests must be added to the release branch due to the release process. Then, make sure that all GitHub workflows successfully pass for the release branch.
This step will actually publish the Performance Lab update and any pending standalone plugin updates managed through the WordPress/performance GitHub repository. Please ensure all of the pending updates are ready to be published.
To publish the Performance Lab release, create a new release tag for the plugin on GitHub. The release tag should use the version number as its name, and it should be created from the release branch release/{versionNumber}. Finally, add the changelog (it can be found in the readme.txt file) to the release description and create the release.
At this point, test the update process from your WordPress site, getting the plugin from 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/. The main aspects to test at this point are:
Install or update the plugin via wordpress.org, ZIP upload, WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/, etc.
Test the plugin on different WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. versions supported.
Test the plugin on a multisiteMultisiteMultisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. environment as well.
Make sure there are no PHP errors or warnings and that the high-level functionality works.
After successful testing, inform the other maintainers on Slack that the new release has been published and that committing may continue.
Since the release branch was branched off the main branch trunk, the latter now needs to be updated to include any additional changes made to the release branch since.
To do that, open a pull request from the release branch to trunk (can be done via 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.) and ask two maintainers to approve it. The code in this pull request does not need to be closely reviewed since it was already approved prior, so this is mostly a formal approval.