Title: Releasing a Standalone Plugin
Author: Felix Arntz
Published: April 8, 2024
Last modified: July 29, 2025

---

# Releasing a Standalone Plugin

## In this article

 * [Releasing as part of the Performance Lab release process](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-with-performance-lab)
 * [Releasing outside of the Performance Lab release process](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-individual-plugin)

The [`WordPress/performance` GitHub repository](https://github.com/WordPress/performance)
is used to develop and maintain several standalone plugins with distinct performance
features. Similar to [releasing the Performance Lab plugin](https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/)
which references the other plugins, these standalone plugins also require regular
releases.

This documentation is largely obsolete. Normal releases of the plugins in Performance
Lab should now follow [Releasing the Performance Lab Plugin](https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/).

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:

    ```wp-block-code
    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/](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](https://github.com/WordPress/performance/blob/trunk/plugins.json).
 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 by the repository owner. [https://github.com/](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/](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](https://github.com/WordPress/performance/milestones)
    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 readme -- --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](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-with-performance-lab).
 * 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](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-individual-plugin).

## 󠀁[Releasing as part of the Performance Lab release process](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-with-performance-lab)󠁿

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](https://github.com/WordPress/performance/actions/workflows/deploy-plugins.yml).

Note that _all_ standalone plugins that satisfy the [aforementioned criteria](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#standalone-plugin-requirements)
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](https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/)
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.

## 󠀁[Releasing outside of the Performance Lab release process](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#release-individual-plugin)󠁿

To release a specific standalone plugin decoupled from Performance Lab, the [GitHub workflow to deploy standalone plugins](https://github.com/WordPress/performance/actions/workflows/deploy-plugins.yml)
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](https://make.wordpress.org/performance/handbook/performance-lab/releasing-a-standalone-plugin/?output_format=md#standalone-plugin-requirements),
please follow these steps:

 1. Open a pull request ([example](https://github.com/WordPress/performance/pull/1154))
    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](https://github.com/WordPress/performance/actions/workflows/deploy-plugins.yml),
    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.

First published

April 8, 2024

Last updated

July 29, 2025

[  Previous: Releasing the Performance Lab Plugin(s)](https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/)

[  Next: WordPress Core](https://make.wordpress.org/performance/handbook/wordpress-core/)