wp-plugin-release

Name: wp-plugin-release
Author: mralaminahamed

25stars3forks

How to install wp-plugin-release?

mralaminahamed/wp-dev-skills/wp-plugin-release

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-plugin-release

Installs into the current project.

Summary

Use when bumping a WordPress plugin version or cutting a release — syncing version across all sources: plugin header (Version: X.Y.Z), version constant (define MY_PLUGIN_VERSION), readme.txt (Stable tag + Changelog + Upgrade Notice), CHANGELOG.md, and .pot Project-Id-Version; fol

Files · 1

View on GitHub

SKILL.md

1	# WordPress Plugin Release / Version Sync
2
3	> Model note: Mechanical file edits — works well on `haiku`. No reasoning across ambiguous code; all sources are explicit (header, constant, readme.txt, changelog).
4
5	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.
6
7	## When to use
8
9	- "Release X.Y.Z", "bump the version", "update the changelog / readme.txt".
10	- After substantial work has landed under an unreleased version.
11
12	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`.
13
14	## First: determine the real current state
15
16	```bash
17	git tag # any release tags?
18	gh release list # any published releases?
19	grep -n "Version:" *.php # plugin header
20	grep -n "_VERSION'" *.php # version constant
21	grep -n "Stable tag" readme.txt
22	```
23
24	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.
25
26	## Sources to update (all, in lockstep)
27
28	1. Plugin header `* Version: X.Y.Z` (main plugin file).
29	2. Version constant `define( 'PLUGIN_VERSION', 'X.Y.Z' )`.
30	3. `readme.txt` `Stable tag: X.Y.Z` — and `Tested up to` / `Requires PHP` if they changed.
31	4. `readme.txt` Changelog — add a `= X.Y.Z =` block listing what shipped (security, features, fixes), grouped.
32	5. `readme.txt` Upgrade Notice — add `= X.Y.Z =` one-liner (why upgrade).
33	6. `.pot` — regenerate so `Project-Id-Version` matches and new strings are captured:
34	```bash
35	composer makepot # or: wp i18n make-pot . languages/<slug>.pot --exclude=...
36	```
37
38	## Do NOT bump
39
40	- Schema / DB version (e.g. `LicenseModel::$db_version`) — independent of plugin version. Only bump when the table actually changed, since it gates data migrations.
41	- Historical changelog entries or point-in-time docs.
42
43	## Verify
44
45	```bash
46	composer lint && composer analyze && composer test
47	grep -rn "X\.Y\.Z\\|<old version>" --include=*.php --include=readme.txt . # confirm sync, spot stragglers
48	```
49
50	Then commit (`docs:`/`chore:` for a pure version+readme bump), and ship via the repo's contribution flow (branch → PR → merge; never squash if the repo says so).
51
52	## References
53
54	- `references/readme-txt-skeleton.txt` — full WP.org `readme.txt` skeleton (all sections) with the release-sync checklist of every version source baked in as a trailing comment.
55	- `references/release-checklist.md` — pre-release checklist: code, version sync, changelog, zip hygiene, and post-release verification steps
56	- `references/svn-deploy.md` — SVN deploy workflow: initial checkout, trunk update, assets directory, tagging a release, and Stable tag mechanics

People who liked this also viewed

6 picks

Type

wp-plugin-release

25stars3forks

View on GitHub

How to install wp-plugin-release?

mralaminahamed/wp-dev-skills/wp-plugin-release

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-plugin-release

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# WordPress Plugin Release / Version Sync
2
3	> Model note: Mechanical file edits — works well on `haiku`. No reasoning across ambiguous code; all sources are explicit (header, constant, readme.txt, changelog).
4
5	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.
6
7	## When to use
8
9	- "Release X.Y.Z", "bump the version", "update the changelog / readme.txt".
10	- After substantial work has landed under an unreleased version.
11
12	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`.
13
14	## First: determine the real current state
15
16	```bash
17	git tag # any release tags?
18	gh release list # any published releases?
19	grep -n "Version:" *.php # plugin header
20	grep -n "_VERSION'" *.php # version constant
21	grep -n "Stable tag" readme.txt
22	```
23
24	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.
25
26	## Sources to update (all, in lockstep)
27
28	1. Plugin header `* Version: X.Y.Z` (main plugin file).
29	2. Version constant `define( 'PLUGIN_VERSION', 'X.Y.Z' )`.
30	3. `readme.txt` `Stable tag: X.Y.Z` — and `Tested up to` / `Requires PHP` if they changed.
31	4. `readme.txt` Changelog — add a `= X.Y.Z =` block listing what shipped (security, features, fixes), grouped.
32	5. `readme.txt` Upgrade Notice — add `= X.Y.Z =` one-liner (why upgrade).
33	6. `.pot` — regenerate so `Project-Id-Version` matches and new strings are captured:
34	```bash
35	composer makepot # or: wp i18n make-pot . languages/<slug>.pot --exclude=...
36	```
37
38	## Do NOT bump
39
40	- Schema / DB version (e.g. `LicenseModel::$db_version`) — independent of plugin version. Only bump when the table actually changed, since it gates data migrations.
41	- Historical changelog entries or point-in-time docs.
42
43	## Verify
44
45	```bash
46	composer lint && composer analyze && composer test
47	grep -rn "X\.Y\.Z\\|<old version>" --include=*.php --include=readme.txt . # confirm sync, spot stragglers
48	```
49
50	Then commit (`docs:`/`chore:` for a pure version+readme bump), and ship via the repo's contribution flow (branch → PR → merge; never squash if the repo says so).
51
52	## References
53
54	- `references/readme-txt-skeleton.txt` — full WP.org `readme.txt` skeleton (all sections) with the release-sync checklist of every version source baked in as a trailing comment.
55	- `references/release-checklist.md` — pre-release checklist: code, version sync, changelog, zip hygiene, and post-release verification steps
56	- `references/svn-deploy.md` — SVN deploy workflow: initial checkout, trunk update, assets directory, tagging a release, and Stable tag mechanics

People who liked this also viewed

6 picks

Type