Use this guide to publish a stable client and plugin, retry a WordPress.org deployment, or update the plugin-directory screenshots.
Before starting
Choose a tested commit on trunk and the version you want to release. The WordPress.org publishing workflows currently allow the GitHub account adamziel. Being a repository administrator does not bypass that check. If you cannot start a deployment, ask the publishing maintainer.
The deployment needs the svn GitHub Actions environment with SVN_USERNAME and SVN_PASSWORD. The current SVN username is zieladam, with that exact case. Use its generated SVN account password, not its WordPress.org login password. The version-bump workflow also needs GH_TOKEN from an account allowed to bypass the trunk ruleset.
Publish a stable version
- Open Tag Release and run it on
trunk. Choosepatch,minor,major, or enter a custom version. - Check the tag it creates, in the form
vMAJOR.MINOR.PATCH. The build uses that tag to publish the GitHub release and Composer packages. - Check Deploy to WordPress.org. It rebuilds the client and downloads-only plugin from the tag, validates them, and uploads them to the Reprint SVN repository. It does not deploy replacement attachments from a GitHub release. Drafts and prereleases are rejected.
- Download the stable client and check its version. Check the version and download on the plugin page.
The workflow also opens and merges a PR for the next -dev version on trunk. Before merging it, the workflow checks that the exact commit changes only the plugin version strings. A failed version-only check stops that bump; it does not undo the release tag. This version-only PR can merge even if the full test suite fails. Other PRs still require normal CI.
The version-bump check uses the token’s admin bypass. If you need an approval rule that workflow edits cannot remove, configure required reviewers on the svn environment separately.
Check the client download
Each release stores the PHAR at downloads/VERSION/reprint.phar, outside the plugin’s trunk and tags directories. The client is therefore not included when someone installs the WordPress plugin.
The unversioned WordPress.org URL points to the highest stable version already published in downloads/. Rerunning an older release does not move it backward. The workflow uploads the client before the plugin so the new readme does not link to a download that is still missing.
Retry a deployment
Run Deploy to WordPress.org manually and enter the existing release tag. It rebuilds from that tag, so changing a GitHub release attachment will not change the deployment.
The client upload can run again. An already-published plugin version is left unchanged. Check the failing job before deciding whether you need a new version.
Update screenshots without releasing code
Run Update WordPress.org screenshots on trunk. It uses images in .wordpress-org/ and captions in the plugin readme’s Screenshots section. It updates the published assets and that readme section, leaving the plugin PHP, version, requirements, and other text unchanged.
This job uses the same svn environment and deployment queue as releases. After it completes, check the images and captions on the plugin page.