Bump the seQura WooCommerce plugin version across the two coupled locations (sequra/sequra.php header and sequra/readme.txt stable tag + changelog), keeping them in sync and writing the changelog entry. Use when releasing a new plugin version.
Install
mkdir -p .claude/skills/version-bump-sequra && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13201" && unzip -o skill.zip -d .claude/skills/version-bump-sequra && rm skill.zipInstalls to .claude/skills/version-bump-sequra
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Bump the seQura WooCommerce plugin version across the two coupled locations (sequra/sequra.php header and sequra/readme.txt stable tag + changelog), keeping them in sync and writing the changelog entry. Use when releasing a new plugin version.About this skill
Version bump (seQura Payment Gateway for WooCommerce)
The plugin version lives in two files that must stay in sync. Bumping one
without the other ships a broken release: WordPress reads the Version: header
to detect updates, and the Stable tag: in readme.txt is what wordpress.org
serves. Always change both, plus add a changelog entry.
The two coupled locations
sequra/sequra.php— the plugin header:* Version: 4.3.2sequra/readme.txt— the WordPress.org readme:- The stable tag near the top:
Stable tag: 4.3.2 - A new entry under
== Changelog ==(entries are newest-first):
Note: the existing entries use a literal TAB between the version and the trailing= 4.3.3 = * Fixed: <what changed>. * Changed: <what changed>.=(= 4.3.2\t=). Match that exact format.
- The stable tag near the top:
There is no PHP version constant — these two files are the only sources of
truth. Do not invent a SEQURA_VERSION define.
Procedure
Given a target version X.Y.Z:
-
Confirm the current version and the target. Read the current value from
sequra/sequra.php(Version:) andsequra/readme.txt(Stable tag:) and make sure they already agree. If they don't, surface the mismatch before touching anything — that's an existing bug, not something to silently paper over. -
Decide the bump (semver): patch for fixes, minor for backwards-compatible features, major for breaking changes. If the user didn't specify, ask.
-
Edit
sequra/sequra.php— update theVersion:header toX.Y.Z. -
Edit
sequra/readme.txt:- Update
Stable tag:toX.Y.Z. - Insert a new
= X.Y.Z\t=block at the top of the== Changelog ==section (above the previous newest entry). Summarise the changes since the last release as* Fixed:/* Changed:/* Added:bullets. If anintegration-coreupgrade is part of the release, include a* Changed: Update integration-core library to version vA.B.C.line, as prior entries do. - If WordPress / WooCommerce "Tested up to" versions changed this release,
also update
Tested up to:near the top and mention it in the changelog.
- Update
-
Verify the two files agree. Re-read both; the version string must be byte-identical in
sequra.php(Version:) andreadme.txt(Stable tag:), and the new changelog block's version must match too. -
Sanity-check the build doesn't break:
bin/make_zipreads the version from thesequra.phpVersion:header (grep "Version:" sequra.php) to name the artifact, so the header format must stayVersion: X.Y.Z.
Tagging / release
Committing and tagging is a separate, deliberate step — do it only when the user asks to release:
- Commit the version bump (use the
sq-git:commitskill). - The git tag convention for this repo is the bare version
X.Y.Z(checkgit tagfor the existing pattern before tagging). - Publishing to wordpress.org is handled separately by
bin/publish_to_wordpress.sh— do not run it as part of a routine bump unless explicitly asked.
Checklist
-
sequra/sequra.phpVersion:=X.Y.Z -
sequra/readme.txtStable tag:=X.Y.Z - New
= X.Y.Z =changelog block added at the top of== Changelog == -
Tested up to:updated if WP/WC support changed - Both version strings verified identical