Iter-46 audit found that 6 of 9 SDK CHANGELOG.md files still mark their latest entry as — Unreleased even though the matching git tag exists and the package is on the registry. Tracking here for visibility — happy to PR-fix all 6 in one batch on your signal.
What's stale
| Repo |
CHANGELOG heading |
Reality |
Should be |
cryptohopper-cli |
## 0.5.0-alpha.1 — Unreleased |
Tag cli-v0.5.0-alpha.1 exists; published as @cryptohopper/cli@0.5.0-alpha.1 |
## 0.5.0-alpha.1 — 2026-04-25 |
cryptohopper-node-sdk |
## 0.4.0-alpha.1 — Unreleased |
Tag sdk-v0.4.0-alpha.1; npm shows 0.4.0-alpha.1 |
## 0.4.0-alpha.1 — 2026-04-24 |
cryptohopper-python-sdk |
## 0.4.0a1 — Unreleased |
Tag py-v0.4.0a1; PyPI shows 0.4.0a1 |
## 0.4.0a1 — 2026-04-24 |
cryptohopper-go-sdk |
## v0.4.0-alpha.1 — Unreleased |
Tag v0.4.0-alpha.1; pkg.go.dev resolves it |
## v0.4.0-alpha.1 — 2026-04-24 |
cryptohopper-ruby-sdk |
## 0.1.0.pre.alpha.1 — Unreleased |
Tag rb-v0.1.0.pre.alpha.1; RubyGems shows 0.1.0.pre.alpha.1 |
## 0.1.0.pre.alpha.1 — 2026-04-24 |
cryptohopper-rust-sdk |
## 0.1.0-alpha.1 — Unreleased |
Tag rs-v0.1.0-alpha.1; crates.io shows 0.1.0-alpha.1 |
## 0.1.0-alpha.1 — 2026-04-24 |
The other three SDKs (PHP, Dart, Swift) already have correct release dates.
Why it matters
Anyone reading a CHANGELOG to figure out "what's in this release" sees "Unreleased" and reasonably concludes the version isn't shipped — even though it is. It also undermines the next release: the next release-bump PR has to either fix the stale heading in passing (silent doc change buried in a feature PR) or carry forward the inaccuracy.
Likely root cause
Tag-driven release workflows that don't auto-update the CHANGELOG date. The "Unreleased" placeholder is the standard "Keep a Changelog" convention for the WIP entry — the bug is that it wasn't replaced with the real release date when the tag was pushed.
Fix shape
Each fix is a one-line replacement, e.g.:
-## 0.4.0-alpha.1 — Unreleased
+## 0.4.0-alpha.1 — 2026-04-24
Six trivial PRs (one per repo). Or one comb if you'd rather see them grouped.
Why I'm filing here, not as 6 PRs
PR review queue is already at 13 across the org. Adding 6 more 1-line PRs at the same time felt like noise. Open to either approach — say the word and I'll push the PRs.
Bonus: prevention
Worth considering as a follow-up: have each repo's release workflow sed-replace ## <version> — Unreleased with ## <version> — $(date +%F) before the tag-parity check, then commit that change back to the release tag. Floats the burden off humans and onto CI. (Requires a small change to the release workflow on each repo; can also be one tracking PR.)
Iter-46 audit found that 6 of 9 SDK
CHANGELOG.mdfiles still mark their latest entry as— Unreleasedeven though the matching git tag exists and the package is on the registry. Tracking here for visibility — happy to PR-fix all 6 in one batch on your signal.What's stale
cryptohopper-cli## 0.5.0-alpha.1 — Unreleasedcli-v0.5.0-alpha.1exists; published as@cryptohopper/cli@0.5.0-alpha.1## 0.5.0-alpha.1 — 2026-04-25cryptohopper-node-sdk## 0.4.0-alpha.1 — Unreleasedsdk-v0.4.0-alpha.1; npm shows0.4.0-alpha.1## 0.4.0-alpha.1 — 2026-04-24cryptohopper-python-sdk## 0.4.0a1 — Unreleasedpy-v0.4.0a1; PyPI shows0.4.0a1## 0.4.0a1 — 2026-04-24cryptohopper-go-sdk## v0.4.0-alpha.1 — Unreleasedv0.4.0-alpha.1; pkg.go.dev resolves it## v0.4.0-alpha.1 — 2026-04-24cryptohopper-ruby-sdk## 0.1.0.pre.alpha.1 — Unreleasedrb-v0.1.0.pre.alpha.1; RubyGems shows0.1.0.pre.alpha.1## 0.1.0.pre.alpha.1 — 2026-04-24cryptohopper-rust-sdk## 0.1.0-alpha.1 — Unreleasedrs-v0.1.0-alpha.1; crates.io shows0.1.0-alpha.1## 0.1.0-alpha.1 — 2026-04-24The other three SDKs (PHP, Dart, Swift) already have correct release dates.
Why it matters
Anyone reading a CHANGELOG to figure out "what's in this release" sees "Unreleased" and reasonably concludes the version isn't shipped — even though it is. It also undermines the next release: the next release-bump PR has to either fix the stale heading in passing (silent doc change buried in a feature PR) or carry forward the inaccuracy.
Likely root cause
Tag-driven release workflows that don't auto-update the CHANGELOG date. The "Unreleased" placeholder is the standard "Keep a Changelog" convention for the WIP entry — the bug is that it wasn't replaced with the real release date when the tag was pushed.
Fix shape
Each fix is a one-line replacement, e.g.:
Six trivial PRs (one per repo). Or one comb if you'd rather see them grouped.
Why I'm filing here, not as 6 PRs
PR review queue is already at 13 across the org. Adding 6 more 1-line PRs at the same time felt like noise. Open to either approach — say the word and I'll push the PRs.
Bonus: prevention
Worth considering as a follow-up: have each repo's release workflow
sed-replace## <version> — Unreleasedwith## <version> — $(date +%F)before the tag-parity check, then commit that change back to the release tag. Floats the burden off humans and onto CI. (Requires a small change to the release workflow on each repo; can also be one tracking PR.)