docs: version-parts.md dokumentiert den --migration-required-Ruecknahmepfad
CI / verify (push) Successful in 53s
Release / release (push) Successful in 36s

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/version-parts.md
This commit is contained in:
2026-09-10 20:04:17 +02:00
parent 54d9540c08
commit 11cbb15e65
3 changed files with 23 additions and 2 deletions
+11 -1
View File
@@ -35,7 +35,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
---
## 5.0.0-beta.5 - 2026-09-10 - Konfidenz-Mechanismus ersatzlos entfernt
## 5.0.0-beta.6 - 2026-09-10 - version-parts.md dokumentiert den --migration-required-Ruecknahmepfad
**Author:** Torben Nehmer
@@ -58,6 +58,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
- dist export erzeugt die TOC-Region nach dem Marker-Strip neu (CI-Fund im Export-Replay)
- Konfidenz-Mechanismus ersatzlos entfernt
- Konfidenz-Mechanismus ersatzlos entfernt
- version-parts.md dokumentiert den --migration-required-Ruecknahmepfad
<!-- /wikitool:bumps -->
@@ -985,6 +986,15 @@ ist der mechanische Strip der zwei Felder über den betroffenen Korpus,
mitsamt der Invariante, die ein automatisierter Lauf einhalten muss (kein
`modified:`-Bump, byte-identischer Body, unveränderte Referenzarrays).
Nachgezogen in `-beta.6`: `instructions/dev/version-parts.md` Schritt 6
beschreibt den Rücknahmepfad jetzt selbst. `tools/CONTRACT.md` führte das neue
Flag bereits, aber die Instruction, die eine Sitzung *vor* einem Bump liest,
kannte den Fall nicht — dieselbe Sitzung ist genau darüber gestolpert. Der
Abschnitt nennt auch, warum ihn nichts meldet: die Zeile ist
maschinengeschrieben, `docs verify` genügt ihr bloßes Vorhandensein, und die
Eskalationsprüfungen laufen nur auf dem Bump, der die Grenze *zuerst*
überschreitet.
---
## 4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet
+1 -1
View File
@@ -1 +1 @@
5.0.0-beta.5
5.0.0-beta.6
+11
View File
@@ -157,6 +157,17 @@ the three-line test below is usually enough.
migrate, with nothing telling it how, is a dead end. Like `--breaking`, both persist across
later bumps of the same candidate without being repeated.
**A `--no-migration` answer can turn out wrong later in the same candidate**, and that is not
a hand-edit: a bump escalates, a second change lands under the same running number, and now
content does have to move after all. Write the migration document first, then retract the line
with `version bump --migration-required` - it removes the `**Migration:** none required` line
the earlier bump wrote, and refuses unless a document already targets the new base. Nothing
else takes that statement back: the line is machine-written (invariant 1), `docs verify` is
satisfied by its bare presence, and the escalation checks in this step run only on the bump
that *first* crosses the boundary - so a candidate that keeps a stale `none required` line is
never reported by anything. The 5.0.0 candidate is the case: it declared `--no-migration` for
a TOC-verification change, then absorbed a schema removal that migrates 152 pages.
7. **Fix the candidate once it is ready to ship.** `version bump` only ever opens or escalates
one; nothing turns it into a release except `tools/wikitool version release`, which strips the
`-beta.N` suffix and closes the entry - see its row in `tools/CONTRACT.md`. That is also the