Releasing a Standalone Plugin

The WordPress/performance GitHub repository is used to develop and maintain several standalone plugins with distinct performance features. Similar to releasing the Performance Lab plugin which references the other plugins, these standalone plugins also require regular releases.

For the following instructions, the $plugin_slug and $plugin_version variables should be set in Bash to facilitate entering the commands. For example, they could be set as follows:

plugin_slug="speculation-rules"
plugin_version="1.2.1"

For any 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to be released, all of the following requirements have to be met:

1. Ensure the plugin’s slug ($plugin_slug) is present in the plugins.json file.
2. Ensure the plugin’s version number ($plugin_version) in 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. https://github.com/ repository codebase is consistent (between the readme.txt headerHeader The 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., the plugin main file header, and the constant defined in the plugin main file). This can be done automatically via npm run versions -- --plugin=$plugin_slug.
3. Ensure the plugin’s version number in the GitHub repository codebase is higher than the currently published version in the wordpress.orgWordPress.org 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. https://wordpress.org/ plugin directory (for an update), or there is no published version in the wordpress.org plugin directory yet (for a first-time release). (TODO: This should be automated.)
4. Make sure that all issues and PRs in the plugin’s next milestone are closed. (After the release is complete, close the milestone and open a new one named “$plugin_slug n.e.x.t“.)
5. Make sure that any n.e.x.t version references have been updated via npm run since -- --plugin $plugin_slug.
6. Ensure the plugin’s readme.txt already contains the changelog section with all entries for the new version. You can use npm run changelog -- --plugin $plugin_slug.

There are currently two alternative paths to releasing a new version of a standalone plugin from the GitHub repository:

• By default, any pending updates for standalone plugins are released as part of the overarching Performance Lab release process.
• If releasing an update to a standalone plugin outside of the Performance Lab release cadence is needed, it is possible using an individual process for that plugin.

Releasing as part of the Performance Lab release process

Whenever a new version of the Performance Lab plugin is released (typically once a month), all standalone plugins which are pending an update are released as part of the same process, using a separate GitHub workflow to deploy standalone plugins.

Note that all standalone plugins that satisfy the aforementioned criteria will be automatically released. It is therefore 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.

For all standalone plugins that meet these requirements, the process described in the article for releasing Performance Lab will automatically publish the updates.

No GitHub tags or releases specific to the standalone plugins are created. While this may change in the future, it is currently the expected behavior.

Top ↑

Releasing outside of the Performance Lab release process

To release a specific standalone plugin decoupled from Performance Lab, the GitHub workflow to deploy standalone plugins needs to be manually dispatched. At the moment, there is no formal process defined for this, so caution is advised.

Due to the limitations of this process, please only use this approach in coordination and accordance with other members of the WordPress Performance Team.

Once the code for the standalone plugin to release is ready and satisfies the aforementioned criteria, please follow these steps:

1. Open a pull request (example) with the above changes (e.g. from a branch release-plugin/$plugin_slug-$plugin_version). And get two reviewers to approve. Prior to merging this PR, use this branch for the workflow 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. in the next step.
2. In the workflow UI, expand the “Run workflow” popover.
3. Select the branch from step 1.
4. Enter the exact plugin slug ($plugin_slug) used in the wordpress.org plugin directory.
5. (Recommended, but optional) Check the “Debug mode” box so that you can first test whether the workflow completes successfully without actually deployingDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. the update.
6. Click the “Run workflow” button.

The workflow will deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. the new version to wordpress.org, unless “Debug mode” was enabled. Once the workflow has successfully completed, you should find the new version on wordpress.org. No GitHub tag or release for the plugin is created. While this may change in the future, it is currently the expected behavior.

Last updated: July 16, 2024