fix(release): treat unchanged versions as ordinary merges

[Reaan06]

Closes #10

Type

• Bug fix
• New user-facing capability
• Maintenance/tooling
• Documentation only
• Code refactoring
• Breaking change

Summary

• Detect unchanged package versions before attempting strict release validation.
• Keep valid stable increases on the existing annotated-tag path.
• Add regression tests for ordinary merges and invalid release transitions.

Changes

File	Change
.github/workflows/tag-release.yml	Delegate version classification to the testable detector while preserving provenance and tag safeguards.
scripts/detect-release.mjs	Add pure release-transition detection and GitHub Actions output.
tests/detect-release.test.mjs	Cover unchanged, valid, invalid, lower, prerelease, and build-metadata transitions.

Test Plan

• npm test
• node --test tests/detect-release.test.mjs
• git diff --check
• Shellcheck: N/A, no shell scripts changed.
• Skills tested in an agent: N/A, no skill behavior changed.

Contributor Checklist

• Linked the approved issue Treat unchanged package versions as ordinary merges #10.
• Added exactly one type:* label (type:chore).
• Ran shellcheck where applicable; no shell scripts changed.
• Skills tested where applicable; no skill behavior changed.
• Updated the ODD task document with scope and evidence.
• Used Conventional Commit messages.
• No Co-Authored-By trailers.

[egdev6]

Reviewed by running it rather than only reading it, and against the exact case that broke main rather than a synthetic one. No blockers here, and the fix does what issue #10 asks for.

The regression case is really fixed

With BEFORE=4aca7a4 and GITHUB_SHA=9561127 (the merge of #8 that failed in run 35189816887), the step body from main still exits 1 with Release version must strictly increase SemVer precedence: 0.1.0 -> 0.1.0, while the step body from this PR exits 0 writing only should_tag=false, so no tag is created. Same input, now classified as an ordinary merge.

Also verified: the modified YAML parses; the provenance step and the should_tag == 'true' gate on the tag job are untouched; detectReleaseTransition stays fail-closed for equal, lower, prerelease, build-metadata, invalid, and missing-argument inputs (exit 1 in every case, identical on Node 22 and Node 24); importing detect-release.mjs has no side effects; and the seven new tests pass 7/7 with node --test on both Node versions.

One coverage gap, and it is mine to resolve rather than yours

On this branch npm test is still npm run validate, so CI does not execute the new test file and the green check on this PR proves nothing about it. Relying on #20 does not close the gap either, because #20 invokes node --test tests, a form that fails with MODULE_NOT_FOUND on Node 22 and Node 24. With a plain node --test, auto-discovery picks this file up (7/7 confirmed). I will land #20 with the invocation fixed, and then these tests run in CI automatically.

Smaller items

• On the tag path, $GITHUB_OUTPUT ends up with should_tag twice (should_tag=false from the initial line, then should_tag=true). The last value wins and this is pre-existing, but the task document says duplicate output keys are avoided, which is not true. Either correct that claim or write the output once.
• tests/detect-release.test.mjs passes new URL(...).pathname to spawnSync, which yields /C:/... on Windows and breaks the CLI subtest there. fileURLToPath is what detect-release.mjs already uses.
• Invoking the script through a symlink makes the main-module guard miss, so it exits 0 with empty stdout and the workflow degrades to no-tag silently instead of failing. It is not reachable through Actions, and the same pattern exists in validate-package.mjs, so I am only noting it.
• validate-package.mjs --release-transition now has no consumer in the workflows.

For the record, 0.1.0 -> 0.1.0+build.1 is rejected even though SemVer precedence is equal. That is fail-closed and consistent with the acceptance criteria in #10, so I am reading it as intended rather than as a finding.

Nothing to change in the code from my side. Thanks for turning this around quickly, it removes the red release run on main.

[Reaan06]

Also reviewed PR #21. The release-detection logic is working and Package CI is green.

I found two follow-ups before merge:

1. npm test still only runs validate, so tests/detect-release.test.mjs is not executed in CI.
2. The CLI test uses new URL(...).pathname, which is not portable on Windows; use fileURLToPath(...) instead.

The duplicate should_tag output on the release path is a smaller cleanup. I found no functional blocker in the detector itself.

[Copilot]

🟢 Approval recommended

No unresolved review comments remain, and the changes include regression coverage.

Pull request overview

Updates release detection so unchanged versions are treated as ordinary merges while valid stable increases still create annotated tags.

Changes:

• Added release-transition detection and GitHub Actions output.
• Integrated detection into the release workflow.
• Added regression tests and task documentation.

File summaries

File	Summary
tests/detect-release.test.mjs	Tests valid, unchanged, and invalid transitions.
scripts/detect-release.mjs	Classifies release transitions and emits workflow output.
odd/tasks/issue-10-release-detection.md	Records scope, decisions, and verification.
.github/workflows/tag-release.yml	Uses detection before tagging while preserving safeguards.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.