docs: record 0.2.0 in the changelog on main - #37
Open
RobertoIskandarani wants to merge 1 commit into
Open
Conversation
Two added lines: the `## [0.2.0] - 2026-09-09` heading and the now-empty `[Unreleased]` above it. No note is edited, moved or reworded. Verified rather than asserted: the resulting `## [0.2.0]` section is byte-identical to the one at the `v0.2.0` tag, 204 lines, checked by extracting both and diffing. Byte-exactness is the rule here and it holds, unlike the 0.1.0 back-port. That one had to depart from it deliberately, because the tagged section carried `Changed` and `Fixed` with a migration note on a *first* release — deltas against pre-release states, meaningless to anyone reading published notes. Nothing like that applies to 0.2.0: it is a real delta against 0.1.0, its sections describe changes that happened, and the migration notes have somewhere to migrate from. So the copy is exact and any correction to these notes belongs in the GitHub Release body rather than here. The release flow still does not do this by itself — `cut-release` opens a back-port PR that bumps POM versions and nothing else, and `release.yml` reads the section on the release branch, which is deleted post-tag. Third release in a row that needs this by hand.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
maincarries the released notes under[Unreleased]. 0.2.0 was stabilized on its own branch and the commit that renamed the heading lives only there —release.ymldeletes the release branch after tagging, so nothing brings it home.What changes
Two added lines: the
## [0.2.0] - 2026-09-09heading, and the now-empty[Unreleased]above it. No note is edited, moved or reworded.Verified rather than assumed: the resulting
## [0.2.0]section is byte-identical to the one at thev0.2.0tag — 204 lines, checked by extracting both and diffing.Byte-exactness holds here, unlike last time
The 0.1.0 back-port had to break that rule on purpose. Its tagged section carried
### Changedwith a migration note and### Fixed, on a first release — entries that were deltas against pre-release states, and meaningless to anyone reading published notes. Correcting that meantmaindeliberately differing from the tag.None of it applies to 0.2.0. It is a real delta against 0.1.0, its sections describe changes that actually happened, and the migration notes have a version to migrate from. So the copy is exact, and any correction to these notes belongs in the GitHub Release body rather than in
main.Third release in a row doing this by hand
cut-releaseopens a back-port PR that bumps POM versions and nothing else;release.ymlreads the section on the release branch and never writes to the default branch. Tracked.Verification
mvn verifygreen across all four modules against the pinned conformance catalog.