Skip to content

2.4.0's breaking changes are under a 2.4.0 heading - #1189

Merged
Rafael-SOWNet merged 1 commit into
masterfrom
breaking-changes-sections
Sep 6, 2026
Merged

Rafael-SOWNet merged 1 commit into
masterfrom
breaking-changes-sections

Conversation

@Rafael-SOWNet

Copy link
Copy Markdown
Member

v2.4.0 was tagged at de7189b1 and published on 2026-08-28, and everything it shipped stayed
under "Unreleased — since 2.3.0". Seventy commits then landed in the same section.

So a reader on 2.4.0 could not tell from this file what they had received, and the next release would
have inherited the section.

Split at the tag, not from memory

An entry is under 2.4.0 if it was in this file at v2.4.0, and under Unreleased if it was added
after. That is decidable rather than a judgement — which is exactly why it was worth doing
mechanically. The entries are interleaved, not appended: reading them and sorting by recollection
would have misattributed some, and misattributing a change to a release is worse than leaving it.

subsections at-a-glance rows
2.4.0 — since 2.3.0 26 47
Unreleased — since 2.4.0 21 49

Verified rather than eyeballed

Both versions of the file sorted and diffed. The only lines that differ are the two headings, the
note under 2.4.0, and the duplicated table header — nothing dropped, reworded or merged. The
### count went 157 → 158, the one addition being the second "At a glance".

One thing left alone deliberately

Sources/Package.Build.props still reads <Version>2.3.0</Version>, which is a release behind. The
comment above it calls it "the version under development", the NuGet workflow takes the real
version from the tag name, and what comes after 2.4.0 is a #746 question rather than bookkeeping.
Flagged rather than guessed at.

Checks

Full suite 9564 passed, 0 failed, 14 skipped. Documentation only.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura

v2.4.0 was tagged at de7189b and published on 2026-08-28, and everything it
shipped stayed under "Unreleased -- since 2.3.0". Seventy commits then landed
in the same section. A reader on 2.4.0 could not tell from this file what they
had received, and the next release would have inherited the same section.

Split at the tag rather than from memory. An entry is under 2.4.0 if it was in
this file at v2.4.0 and under Unreleased if it was added after -- which is
decidable rather than a judgement, and is why this was worth doing mechanically:
the entries are interleaved, not appended, so reading them and sorting by
recollection would have misattributed some.

  26 subsections and 47 at-a-glance rows to 2.4.0
  21 subsections and 49 at-a-glance rows to Unreleased -- since 2.4.0

Verified by sorting both versions of the file and diffing: the only lines that
differ are the two headings, the note under 2.4.0, and the duplicated table
header. Nothing was dropped, reworded or merged. The subsection count went from
157 to 158, the one addition being the second "At a glance".

Sources/Package.Build.props still reads <Version>2.3.0</Version> and is left
alone deliberately. The comment above it calls it "the version under
development", the NuGet workflow takes the real version from the tag name, and
what comes after 2.4.0 is a question for #746 rather than bookkeeping. Flagged
rather than guessed.

Full suite 9564 passed, 0 failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura
@Rafael-SOWNet
Rafael-SOWNet merged commit 68c3add into master Sep 6, 2026
27 checks passed
@Rafael-SOWNet
Rafael-SOWNet deleted the breaking-changes-sections branch September 6, 2026 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant