[Bug] Too easy to get release tags and Cargo.toml version number out of sync

[pdf-amzn]

Describe the bug

It's easy to forget to change the version in Cargo.toml before using the GitHub CLI to construct a release. We should try to have GitHub enforce consistency here.

Possible solutions?

Release Version Check: Options for ExtendDB

Goal: Ensure the Git tag used for a release matches the version in Cargo.toml (e.g., tag v0.1.1 ↔ version = "0.1.1").

Option A: Post-publish check (informational only)

• Workflow triggers on release: [published]
• Fails visibly if tag ≠ Cargo.toml version
• Does not prevent the release from going out — it's already published
• Simplest to implement, relies on humans noticing the failed check

Option B: Tag ruleset + separate publish step

• Workflow triggers on push: tags: ['v*']
• Create a GitHub repository ruleset on tags matching v* requiring the check-version status check to pass
• Release workflow becomes two steps:
  1. git tag v0.1.1 && git push origin v0.1.1 — wait for check
  2. gh release create v0.1.1 --generate-notes — only after check passes
• Enforcement: tag push is blocked if check fails (tag ruleset)
• Caveat: gh release create combines tag push + release creation in one call, so you must push the tag separately first. Requires discipline or a wrapper script.

Option C: Auto-demote to draft on mismatch (recommended)

• Workflow triggers on release: [published]
• If tag ≠ Cargo.toml version: automatically reverts the release to draft via gh release edit --draft
• Brief window (~10-30s) where a bad release is visible before being unpublished
• No discipline required — publish directly and the system catches mistakes
• Happy path: create as draft → review → publish → check passes → stays published
• Can be extended to also gate on CI passing before allowing publish

Comparison

	Prevents bad release?	Requires workflow change?	Complexity
A Post-publish check	❌ No (informational)	No	Low
B Tag ruleset	✅ Yes (strict)	Yes (two-step publish)	Medium
C Auto-demote	⚠️ Mostly (brief window)	No	Low

Recommendation

Option C gives the best balance — it's self-healing, doesn't require changing how anyone creates releases, and the brief visibility window is acceptable for a project of this size. If the brief window is unacceptable, Option B with a tag ruleset is stricter but requires everyone to adopt a two-step release process.