chore(main): release clickhouse-migrator 0.1.0 #3486
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 This auto-generated release PR adds a second
## [0.1.0]CHANGELOG section (dated 2026-07-31) that duplicates the pre-existing one (dated 2026-07-30) — both cite the identical commit1b19a3b/ PR #3236. The root cause is that a prior release PR (#3300) updated the CHANGELOG to 0.1.0 but never updated.release-please-manifest.json, which stayed at 0.0.1, so release-please believes 0.1.0 was never released and regenerates it here. Worth reconciling (drop the stale duplicate section) so 0.1.0 isn't documented twice under two different dates.Extended reasoning...
What happened:
packages/clickhouse/CHANGELOG.mdnow contains two## [0.1.0]headers back-to-back — one added by this PR dated 2026-07-31 (lines 3-8) and a pre-existing one dated 2026-07-30 (lines 10-15, unchanged context). Both sections link the exact same compare range (clickhouse-migrator-v0.0.1...clickhouse-migrator-v0.1.0) and cite the exact same single commit1b19a3b/ PR #3236 under "Features". This is the same version documenting the same change twice, under two different release dates.Root cause:
git logshows commit5088eee("chore(main): release clickhouse-migrator 0.1.0", PR #3300) already added the 2026-07-30 section to the CHANGELOG. However, that prior release PR apparently didn't update (or a later fix reset).release-please-manifest.json, which remained at"packages/clickhouse": "0.0.1"going into this PR. Because release-please's source of truth for "what's already been released" is the manifest, and the manifest still says 0.0.1, it concluded 0.1.0 had never shipped and regenerated a fresh 0.1.0 entry — hence the duplicate. This PR's manifest diff (0.0.1→0.1.0) confirms the jump skips any record of the version having been documented once already.Why nothing upstream caught this: release-please computes the next version and changelog contents purely from the manifest + conventional commits since the last recorded release; it has no cross-check against the CHANGELOG.md file's actual contents, so a manifest/CHANGELOG desync like this (previously introduced by #3300) silently persists and resurfaces on the next release run rather than being detected/reconciled automatically.
Impact: This is confined to human-readable release documentation. No code path parses
CHANGELOG.mdfor version comparisons — the manifest (which will be correct and singular at0.1.0after this PR merges) is what tooling actually relies on. So the practical effect is a confusing/duplicated changelog entry, not a functional or build break. It's worth cleaning up for clarity, but it doesn't block anything from working correctly.Suggested fix: Before merging, drop the newly-added 2026-07-31 section (or merge its content into/replace the 2026-07-30 section) so
packages/clickhouse/CHANGELOG.mdhas a single## [0.1.0]entry. Since the manifest will already be correct (0.1.0) after this merges, no further desync should recur unless the CHANGELOG is manually edited out of sync with the manifest again.Proof walkthrough:
"packages/clickhouse": "0.0.1", but CHANGELOG.md already has a## [0.1.0] (2026-07-30)section (added in chore(main): release clickhouse-migrator 0.1.0 #3300) documenting commit1b19a3b.0.0.1as the last released version for clickhouse.1b19a3b(the same commit already changelogged), and computes the next version as0.1.0again.2026-07-31) for0.1.0and prepends it to CHANGELOG.md, right above the older0.1.0 (2026-07-30)section — producing the duplicate visible in the diff.0.1.0, so after merge the manifest is correct going forward, but the CHANGELOG permanently retains both dated sections for the same version.