version-bump

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 entr

SKILL.md

GitHub

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