wp-plugin-release

# WordPress Plugin Release / Version Sync > **Model note:** Mechanical file edits — works well on `haiku`. No reasoning across ambiguous code; all sources are explicit (header, constant, readme.txt, changelog). Bump a WP plugin version coherently. Prevents the classic drift where the plugin header says one version, the `readme.txt` `Stable tag` another, and the `.pot` a third. ## When to use - "Release X.Y.Z", "bump the version", "update the changelog / readme.txt". - After substantial work has landed under an unreleased version. **Not for:** WP.org SVN deploy (trunk/tags/assets push) — use `wp-org-submission`. First-time plugin submission to the WP.org directory — use `wp-org-submission`. ## First: determine the real current state ```bash git tag # any release tags? gh release list # any published releases? grep -n "Version:" *.php # plugin header grep -n "_VERSION'" *.php # version constant grep -n "Stable tag" readme.txt ``` If header/constant/Stable-tag disagree, that drift IS the problem — pick the target version and sync all of them. Choose the bump by semver: new backward-compatible features → minor; fixes only → patch; breaking → major. Internal-only refactors (dir rename) don't force a major. ## Sources to update (all, in lockstep) 1. **Plugin header** `* Version: X.Y.Z` (main plugin file). 2. **Version constant** `define( 'PLUGIN_VERSION', 'X.Y.Z' )`. 3. **`readme.txt` `Stable tag: X.Y.Z`** — and `Tested up t...