All guides
WordPress DevKit
No guide matches your search.
Prepare a WordPress release
Review migrations, tests, packaging and rollback before you publish a plugin or theme release.
On this page
1. Define the release
Write down the WordPress, PHP and WooCommerce versions you support. Add the changes, the data they affect, the checkout type and the package you will ship. Name the person who can approve the deployment and the person who can restore the previous state.
2. Run the reviews in order
- Start with the plugin or theme review for changes to structure and lifecycle.
- Add the security and REST reviews when access or data boundaries changed.
- Use the migration and operations reviews for upgrades, backfills and maintenance.
- Check the changed behavior with test strategy, PHPStan and the browser journeys that matter.
- Finish with the release engineering review of the final pipeline and package.
3. Ask for the pipeline review
/wp-devkit:release-review .$wp-devkit-ci-cd-and-release-engineering
Review the release pipeline and package without deploying.
Check that the tested archive is the published archive, token permissions and action pinning,
required gates and their skipped-check behavior, version consistency, migration order and rollback readiness.
Report local and hosted checks separately and list unexecuted target checks.4. Collect evidence before you publish
| Question | Evidence |
|---|---|
| Is the archive the one you tested? | Archive digest recorded after the tests and verified again at upload |
| Does it hold only what it should? | File list of the built archive, with no secrets, tests, caches or development data |
| Do the versions agree? | Plugin header, readme stable tag, changelog and git tag compared in one check |
| Do upgrades work? | Install and upgrade from the previous release on realistic disposable data, including an interrupted run |
| Can you go back? | Rollback steps, and the data changes that make a rollback unsafe |
| Are the required checks real? | A deliberately failing change shown to block the merge, and any skipped required jobs explained |
5. Before you publish
- Run the required checks. A failing check stays a failure, so do not regenerate a baseline or widen an ignore rule to make it pass.
- Test the install and upgrade path with realistic disposable data.
- Confirm the rollback limits if a data change cannot be undone.
- Write down the versions, commands, archive identity, evidence and known gaps.
Note
Nothing in this checklist gives the agent permission to publish or deploy. Release readiness covers only the targets and checks you recorded.
Was this page helpful?