version-bump

name	version-bump
description	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.

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

1. sequra/sequra.php — the plugin header:

    * Version:           4.3.2
   

2. sequra/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):

     = 4.3.3	=
     * Fixed: <what changed>.
     * Changed: <what changed>.
     

     Note: the existing entries use a literal TAB between the version and the trailing = (= 4.3.2\t=). Match that exact format.

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:

1. Confirm the current version and the target. Read the current value from sequra/sequra.php (Version:) and sequra/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.

2. Decide the bump (semver): patch for fixes, minor for backwards-compatible features, major for breaking changes. If the user didn't specify, ask.

3. Edit sequra/sequra.php — update the Version: header to X.Y.Z.

4. Edit sequra/readme.txt:

   • Update Stable tag: to X.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 an integration-core upgrade 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.

5. Verify the two files agree. Re-read both; the version string must be byte-identical in sequra.php (Version:) and readme.txt (Stable tag:), and the new changelog block's version must match too.

6. Sanity-check the build doesn't break: bin/make_zip reads the version from the sequra.php Version: header (grep "Version:" sequra.php) to name the artifact, so the header format must stay Version: 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:commit skill).
• The git tag convention for this repo is the bare version X.Y.Z (check git tag for 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.php Version: = X.Y.Z
• sequra/readme.txt Stable 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