Releasing the Plugin

Branch off of trunk

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.

Top ↑

Create a new release branch

At the cutoff time, create a new remote branch release/{milestoneName} from latest trunk, where {milestoneName} is the name of the milestone (which should match the release version). For example, if the milestone is 1.2.0, name the branch release/1.2.0.

Top ↑

Communicate the change with other contributors

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 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 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.

Top ↑

Preparing the release

Top ↑

Create a local release branch

Before making any changes, create a new local branch based on the remote release branch release/{milestoneName}. Make the following changes in that local branch.

Top ↑

Update the version number

The version number needs to be manually updated in the following places:

  • in the plugin 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. in load.php
  • in the PHPPHP PHP (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. 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 betaBeta A 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 Candidate A 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.

Top ↑

Update list of default enabled modules

The default enabled modules are defined in a separate default-enabled-modules.php file which can be automatically generated and updated. Run npm run enabled-modules to update the file based on the latest available non-experimental modules.

Top ↑

Update translation strings

The module headers from the plugin have to be translated using a separate module-i18n.php file which can be automatically generated and updated. Run npm run translations to update the file to reflect the latest available modules.

Top ↑

Update readme.txt

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 PL Plugin 2.5.0, the command needs to be npm run readme -- -m "PL Plugin 2.5.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.

Top ↑

Open a pull request

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 against the release branch release/{milestoneName}. As usual, make sure to request a review from at least 2 plugin maintainers. Once approved, the pull request can be merged.

Top ↑

Publishing the release

Top ↑

Notify maintainers and review release branch

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.

Top ↑

Create the release tag

After that, create a new release tag for the plugin on GitHub. The release tag should have the same name as the corresponding milestone used earlier, and it should be created from the release branch release/{milestoneName}. Finally, add the changelog (it can be found in the readme.txt file) to the release description and create the release.

Top ↑

Review and test the deployment

Once a new version is released on GitHub, the plugin will be deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. to the repository. The deployment workflow progress can be tracked here.

At this point, test the update process from your WordPress site, getting the plugin from 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. The main aspects to test at this point are:

  • Install or update the plugin via, ZIP upload, WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is, etc.
  • Test the plugin on different WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. versions supported.
  • Test the plugin on a multisiteMultisite Multisite 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. 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.

Top ↑

Wrapping up the release

Top ↑

Update trunk

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 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.) 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.

Top ↑

Close the release

As a last action, close the GitHub milestone for the release. Make sure that all issues in the milestone are closed.

Don’t delete the release branch since that branch can be used to later create patch releases from the same state of the codebase.

Last updated: