docs: stage the 2.2 line so the cut can describe it - #557
Merged
Conversation
Three things the cut needs and does not have. The roadmap describes the 2.1 line, and 2.2.0 crosses into a new one. A cut across lines is refused at Step 0 -- the heading and the prose describe the release that shipped, and no rewrite can write a paragraph about a line nobody has described yet -- so the section is staged here, as '## Upcoming - 2.2' above the current one. 'Current stable' keeps naming 2.1.1, which is what is on Central; the cut promotes the staged section and moves 2.1 to 'Previously'. Verified by dry-run: the cut refused before this commit and promotes after it. The README advertised v2.1.2 as in development. The post-release bump writes a patch increment unconditionally, the line was retargeted to 2.2.0 in the changelog and the poms, and this half was left behind -- so develop has been promising a release nobody is building. The cut would overwrite it, but it is wrong now, and nothing guards this half. And the image work merged without a changelog entry, which matters because it carries a behaviour change a reader should meet before upgrading rather than after: an image whose source cannot be read now stops the export instead of vanishing from the document.
The prepared 2.2 roadmap section opened with "2.2.0 is the current release" while sitting under "## Upcoming — 2.2", above a "## Current stable — 2.1" that was still true. cut-release.ps1 promotes the section and renames the heading; it does not rewrite prose, so the sentence has to read correctly on both sides of the cut. It now states what the release brings rather than where it stands. The limits were also written from the wrong end. A table cell does carry direction when it is composed as a paragraph through DocumentTableCell.node(...) — Hebrew reorders and Arabic joins there like anywhere else. What has neither is the plain-string shortcut, which goes through the table's own layout instead of the text pipeline. Saying "a table cell carries no direction" understated a capability that ships, and pointed authors away from the one path that works.
Uh oh!
There was an error while loading. Please reload this page.
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 freeto 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.
Release prep for 2.2.0. Three gaps a readiness audit of
developfound, none of them code.The cut cannot run without the staged section
ROADMAP.mddescribes the 2.1 line and 2.2.0 crosses into a new one.Assert-RoadmapReadyForCutrefuses that in Step 0 — the heading and the prose describe the release that shipped, and no rewrite can produce a paragraph about a line nobody has described yet.Verified both ways with a real dry-run against this branch:
[DRY RUN] ROADMAP.md promote 'Upcoming — 2.2' → 'Current stable', demote 2.1## Current stabledeliberately still names 2.1.1, the version on Central —VersionConsistencyGuardTestholds it there, andaPreparedUpcomingSectionNamesTheLineUnderDevelopmentholds the staged section to the line the poms are on. The cut promotes one and demotes the other.The headline is what the changelog actually contains: right-to-left text through all three backends, and the five bundled script families that render it.
The README promised a release nobody is building
Line 24 read
In development: v2.1.2while the poms and the changelog say 2.2.0. The post-release bump writes a patch increment unconditionally; the line was later retargeted, and this half was left behind. The cut would overwrite it, butdevelophas been advertising it in the meantime, and no guard covers this half of the block —VersionConsistencyGuardTestchecks Latest stable against published versions only.The image change shipped without a changelog entry
#555 merged with no entry, and it carries a behaviour change a reader should meet before upgrading rather than after: an image whose source cannot be read now stops the export instead of disappearing from the document. The entry also records the reason the work was worth doing — the bytes and the dimensions were arriving from different places, so a file rewritten between renders produced a picture embedded at another image's size, silently.
Verification
./mvnw -B -ntp clean verifyover the full reactor —BUILD SUCCESS, 368 green suites.The 9-guard fail-fast list runs green, including the two that constrain this change:
VersionConsistencyGuardTest(the roadmap's current-stable section, its heading, and the staged line) andAgentsGuideGuardTest.Not in this change
The remaining audit findings are not release blockers and are left alone: the open DOCX feature issues (#527, #529, #530), and
cut-release.ps1hardcodingmvnw.cmd, which makes it unrunnable on Linux and macOS.