feat(release): one versioning policy for every repository, and main names the version it released

[soydiloreto]

📝 What changes

A written versioning policy for every DiluxOne repository, in CONTRIBUTING.md ("How a change becomes a version"): major for a big new capability or anything that breaks, minor for additions to what exists, patch for fixes, security and performance; breaking changes only in a major, announced in a minor first; every major states its breaking changes or "none". The big-capability call stays with the maintainer (version:major); the review profile and prompt now say that size is not breakage and that a feat that looks like a new capability gets a one-line suggestion in the summary, never the label.

New scripts/release-markers.sh: check holds the three version markers to the last release, or to the next one once the release pull request is ready; prepare turns a tree into that release pull request (removes the Unreleased. line, stamps the markers). The checks' readme job runs check on every pull request (it reads the labels of the merged pull requests and, through the new next-version.py --with-pull, the pull request's own labels as if it had merged, so a release pull request carrying version:major is checked against that major; the job gets pull-requests: read and the central checkout); the release job runs it before deploying and refuses a commit whose markers name another version. The central CI runs its self-tests. README and the workflow headers describe the new flow.

💡 Why

The release job stamped the version only in its own checkout, so after 2.0.0 shipped DiluxOne Offload's main still says 1.0.0, while every document says main keeps the last released version. Setting the markers in the release pull request (instead of a bot pull request after every release) keeps main right from the moment the release is decided, with no extra pull request.

The policy is the one the maintainer chose after comparing strict SemVer with what other plugins do (WP Offload Media, Elementor, Angular: a major for a big capability or a break; WordPress and WooCommerce: a counter). The pipeline needed no change for it: version:major already wins.

This enforces what the docs already promised, so a repository that followed them needs nothing. The only caller today, DiluxOne Offload, is off by it (1.0.0 against the 2.0.0 release) and records 2.0.0 in its own pull request right after this merges and v2 moves.

🧪 How I tested it

bash scripts/release-markers.sh --test: 22 cases (held/ready, pending or not, a fix merged after a release with no new entry, markers behind or ahead, the constant alone, no constant, no release yet, prepare on a held readme, a = Unreleased = heading, a CRLF readme, a readme that is not held). Run against a copy of DiluxOne Offload's real tree with the labels from next-version.py: it fails naming the three markers at 1.0.0 against 2.0.0. python3 scripts/next-version.py --test includes --with-pull (an open version:major gives the major, a chore adds nothing, a merged pull request counts once). actionlint clean, shellcheck clean.

📸 Screenshots

Not applicable: no screen.

✅ Checklist

• Tests cover the change.
• Docs that describe what changed are updated in this PR.
• No credentials, keys or personal data anywhere in the diff.

🤖 AI-generated · Claude Opus 5.5 (Anthropic)

[dilux-bot]

✍️ The description changed since this review, so nobody has checked it against the code: no auto-merge until a push or the review:full label brings a new review.

Claude review · risk high · complexity high · type feat

The new commits fixed both earlier findings. next-version.py now has a with_pull() helper and a self-test for it: an open version:major gives the major, a chore adds nothing, and a pull request that already merged counts once. The readme-job comment now says why a type:* label the review sets later is missed, and that the release job's marker check stops anything that slips through before SVN. I checked that claim: plugin-release-wp.yml:435 runs release-markers.sh check against the computed version before deploying. The new commits add no new problems. The pull request as a whole is a feat: a versioning policy, marker enforcement in the checks and release jobs, and the release-markers script. It is high risk because it changes release and CI behaviour for every caller. As the description says, DiluxOne Offload must record 2.0.0 in its markers once this merges. The description matches the diff, including the --with-pull tests.

No findings.

_{Policy floor: high (touches high-risk paths: .github/workflows/claude-review.yml, .github/workflows/plugin-checks-wp.yml, .github/workflows/plugin-release-wp.yml, .github/workflows/pull-request.yml, CONTRIBUTING.md …). Reviewed e7b1ef3 (since 61b3c3c; review 3 of 5 automatic). Author trusted for auto-merge: true.}

_{🤖 AI review · claude-opus-5-5 (Anthropic) · $0.09, 4 turns}