Erledigt (2026-10-06). Ausgeliefert im Kandidaten 8.1.0 (noch nicht released):
8.1.0-beta.1, Commit 044943a: Umsetzung 1–5. CI grün: Läufe 572 (verify, pwsh) und 573.
8.1.0-beta.2, Commit 0e15972: Nachzug aus stack-close. Die Abschlussmeldung von version bump verlangte noch pauschal „write its prose“ und nennt jetzt Stichpunkt oder Themenabsatz. CI grün: Läufe 574 und 575.
Anlass
Der 8.0.0-Eintrag in CHANGES.md hatte 129 KB und scheiterte als Release-Notiz an Linux' Argumentgrenze und an Giteas MySQL-Grenze von 65 535 Bytes (#183). Er wurde für das Release von Hand auf 22 KB gekürzt. Dieses Issue regelt, dass Einträge von vornherein kompakt bleiben, statt am Release-Tag gekürzt zu werden. Der ursprüngliche Stub steht wörtlich im ersten Kommentar.
Zielform laut Betreiber: Breaking Changes, ggf. mit Verweis/Listing der nötigen Migrationen; größere Änderungen mit einem Absatz; kleinere mit einem Stichpunkt. Der gekürzte 8.0.0-Eintrag (2ddcd6b) ist das Referenzbeispiel dieser Form.
Befund (vor dem Bau, gegen den Baum geprüft, 2026-10-06)
Ursache war das Modell „ein ###-Changeset pro Bump“, nicht einzelne zu lange Texte. Ein Eintrag wuchs linear mit der Zahl der Bumps, und ein Kandidat sammelt Bumps über Wochen:
664 / 1 045 B (mit Überschrift); Absatz allein max. 895 B
7.0.0
33 709 B
16
1 789 / 3 555 B
6.1.0
24 758 B
8
3 091 / 4 057 B
5.0.0
100 045 B
(vor dem Schichtmodell)
–
instructions/dev/version-parts.md verlangte „a few sentences“ pro Changeset. Das wurde systematisch überschritten und von nichts geprüft. Selbst bei eingehaltenen ~500 B ergäben 80 Bumps 40 KB. Eine reine Längenvorgabe pro Changeset hätte das Problem also nicht gelöst.
Ein Bump mit Migrationsdokument hinterließ keine Zeile im Eintrag, und docs verify akzeptierte das Dokument stillschweigend. 5.0.0 hat seinen Verweis von Hand in den Breaking-Text geschrieben.
version-parts.md behauptete, Bump-Titel und ###-Überschrift seien „the same string“. Der gekürzte 8.0.0 hielt das nicht ein, und nichts prüfte es.
Die Einleitung von CHANGES.md (~4 KB) beschrieb das Format ein zweites Mal – Invariante 8.
release.yml verweigert ab 60 000 Bytes (#183). Das greift aber erst nach dem Fixieren des Kandidaten.
CHANGES.md wird nicht ausgeliefert. Eine Instanz hat keinen versionierten Eintrag, also sind die neuen Prüfungen dort wirkungslos.
Entscheidungen
F1 – Absatz oder Stichpunkt: Urteil der Build-Sitzung (Betreiber, 2026-10-06). Es gibt keine Kopplung an --impact. Absätze sind thematisch und bündeln mehrere Bumps; eine Zuordnung Bump → Absatz ließe sich nicht prüfen. Mechanisch geprüft wird nur das Budget.
F2 – Budget (Betreiber, 2026-10-06): Der oberste versionierte Eintrag hat höchstens 32 000 Bytes (UTF-8, gemessen an der Ausgabe von version notes, halbe Gitea-Grenze). Jeder ###-Abschnitt ist genau ein Absatz (keine Leerzeile im Rumpf) mit höchstens 1 000 Bytes, ohne ###-Zeile. Der Rumpf reicht bis zur nächsten ### - oder ## -Zeile bzw. bis zu ---; Leerzeilen an den Rändern zählen nicht. Geprüft wird in docs verify und in version release vor dem Schreiben. Der Betreiber wählte 1 000 statt 1 500 Bytes. Gemessen wird ohne Überschrift, damit der gekürzte 8.0.0 besteht (1 045 B mit, 895 B ohne).
F3 – Ältere Einträge bleiben unverändert (Betreiber, 2026-10-06). Beide Prüfungen gelten nur für den obersten versionierten Eintrag.
Umsetzung
Eintragsform in instructions/dev/version-parts.md § The candidate model (Schichten 1–4 und ein neuer Budget-Absatz), Schritt 6 (Rücknahme von --no-migration) und Schritt 8. Die Bump-Liste ist die Stichpunktebene. ###-Abschnitte gibt es pro Thema statt pro Bump, je ein Absatz im Budget; ein weiterer Bump zum selben Thema schreibt den vorhandenen Absatz um. „same string“ ist entfallen.
Zielt ein erforderliches Migrationsdokument auf die Basis des Kandidaten, schreibt jeder version bump die Zeile **Migration:** required - instructions/migrations/<datei>.md, mehrere Pfade sortiert und kommagetrennt, am Anker der none required-Zeile. Die beiden Formen schließen sich aus.
--migration-required ersetzt none required durch die required-Zeile.
docs verify hat die neue Prüfung check_migration_line_names_documents: Ein grenzüberschreitender oberster Eintrag muss jedes auf ihn zielende erforderliche Dokument nennen.
Beim Bau präzisiert, ohne die Entscheidungen zu berühren:
Nur obligation: required zählt. Ein offered-Dokument darf eine Instanz ablehnen; 6.0.0 hatte so eines neben einer korrekten none required-Zeile.
--no-migration wird verweigert, solange ein erforderliches Dokument auf die Basis zielt.
Eine verwaiste required-Zeile fällt beim nächsten Bump weg.
Budgetprüfung:version.budget_issues mit ENTRY_MAX_BYTES = 32_000 und CHANGESET_MAX_BYTES = 1_000, dazu docs_verify.check_changelog_budget. version release prüft den Eintrag so, wie er nach dem Release aussähe (auch mit --title und --dry-run). Bei Überschreitung gibt es ERROR und Exit 1, der Abschnitt und seine Größe werden genannt, und nichts wird geschrieben.
CHANGES.md-Einleitung auf zwei Absätze gekürzt, mit Verweis auf version-parts.md. Die Einträge sind unberührt.
Doku-Nachzug:
DEVELOPMENT.md Schritte 2, 4 und 6; stack-build Schritt 4; instructions/migrate-corpus.md.
cli_contract-Datensätze von version bump, version release und docs verify. Der docs verify-Datensatz nannte seine Versions- und Changelog-Prüfungen vorher gar nicht.
Docstrings; tools/CONTRACT.md regeneriert.
In stack-close: die Abschlussmeldung von version bump (0e15972).
Geprüft und unverändert: docs/version-model.md, README.md, tools/README.md, INSTALL.md. Sie machen keine Aussage über die Form eines Eintrags. Eine docs/-Seite fürs Budget braucht es nicht, weil die Regel nur im Ursprungs-Repo greift.
Akzeptanzkriterien
docs verify meldet einen obersten Eintrag über 32 000 Bytes. Test: test_an_entry_over_32000_bytes_is_reported.
docs verify meldet einen ###-Abschnitt mit mehr als einem Absatz und einen, dessen Absatz über 1 000 Bytes liegt; genau 1 000 Bytes bestehen. Tests: test_a_section_with_two_paragraphs_is_reported, test_a_paragraph_over_1000_bytes_is_reported_in_bytes_not_characters, test_a_paragraph_of_exactly_1000_bytes_passes_and_its_heading_is_not_counted.
Ein älterer Eintrag über beiden Grenzen löst keine Meldung aus. Test: test_an_older_entry_over_both_limits_is_not_reported.
docs verify ist grün. Der gekürzte 8.0.0-Eintrag bestand (22 043 B, Absatz max. 895 B), danach der neue 8.1.0-beta-Eintrag (test_this_repos_newest_changelog_entry_is_inside_its_budget).
version bump mit erforderlichem Dokument hinterlässt genau eine required-Zeile; ein zweiter Bump lässt sie byte-gleich. Test: test_bump_names_a_required_migration_document_and_a_second_bump_keeps_it.
--migration-required hinterlässt die required-Zeile mit dem Pfad. Test: test_migration_required_retracts_the_no_migration_line.
docs verify meldet einen grenzüberschreitenden Eintrag ohne Verweis auf sein erforderliches Dokument. Test: test_a_crossing_entry_that_does_not_name_its_migration_document_is_reported.
version release verweigert über dem Budget mit Exit 1; VERSION und CHANGES.md bleiben byte-gleich. Test: test_release_refuses_an_entry_over_budget_and_writes_nothing (drei Fälle).
Die Formregeln stehen nur in version-parts.md, die anderen Dokumente verweisen darauf. „same string“ steht nirgends mehr.
pytest (2352 passed, 3 skipped), docs verify und instructions verify sind grün. CI ist grün auf 044943a (Läufe 572, 573) und 0e15972 (Läufe 574, 575).
Versions-Teil
--minor, --impact medium → 8.1.0-beta.1; der Nachzug kam als --patch mit --impact low → 8.1.0-beta.2. Drop-in in beide Richtungen: Eine Instanz hat keinen versionierten Eintrag, und eine alte Version liest die neue Migrationszeile ohne Fehler. Kein Kommando und kein Flag ist entfallen. Der 8.1.0-Eintrag ist der erste in der neuen Form.
Nicht im Umfang
Die 60 000-Byte-Sperre in release.yml bleibt als letztes Netz (#183).
Ältere Einträge werden nicht gekürzt (F3).
Die Bump-Liste bleibt vollständig und maschinell. Bumps zusammenzulegen bräuchte einen neuen Schreibweg in die maschinenverwaltete Region (Invariante 1); das Gesamtbudget deckt den Fall ab.
Die Sprachmischung der Bump-Titel (EN/DE) ist ein eigenes Thema, falls gewünscht.
## Stand
**Erledigt** (2026-10-06). Ausgeliefert im Kandidaten `8.1.0` (noch nicht released):
- `8.1.0-beta.1`, Commit `044943a`: Umsetzung 1–5. CI grün: Läufe [572](https://gitea.nehmer.net/torben/chemenu/actions/runs/572) (`verify`, `pwsh`) und [573](https://gitea.nehmer.net/torben/chemenu/actions/runs/573).
- `8.1.0-beta.2`, Commit `0e15972`: Nachzug aus `stack-close`. Die Abschlussmeldung von `version bump` verlangte noch pauschal „write its prose“ und nennt jetzt Stichpunkt oder Themenabsatz. CI grün: Läufe [574](https://gitea.nehmer.net/torben/chemenu/actions/runs/574) und [575](https://gitea.nehmer.net/torben/chemenu/actions/runs/575).
## Anlass
Der 8.0.0-Eintrag in `CHANGES.md` hatte 129 KB und scheiterte als Release-Notiz an Linux' Argumentgrenze und an Giteas MySQL-Grenze von 65 535 Bytes (#183). Er wurde für das Release von Hand auf 22 KB gekürzt. Dieses Issue regelt, dass Einträge **von vornherein** kompakt bleiben, statt am Release-Tag gekürzt zu werden. Der ursprüngliche Stub steht wörtlich im ersten Kommentar.
Zielform laut Betreiber: **Breaking Changes, ggf. mit Verweis/Listing der nötigen Migrationen; größere Änderungen mit einem Absatz; kleinere mit einem Stichpunkt.** Der gekürzte 8.0.0-Eintrag (`2ddcd6b`) ist das Referenzbeispiel dieser Form.
## Befund (vor dem Bau, gegen den Baum geprüft, 2026-10-06)
**Ursache war das Modell „ein `###`-Changeset pro Bump“**, nicht einzelne zu lange Texte. Ein Eintrag wuchs linear mit der Zahl der Bumps, und ein Kandidat sammelt Bumps über Wochen:
| Eintrag | Größe | Bumps/Changesets | Changeset Median / Max |
|---|---|---|---|
| 8.0.0 vor #183 | 129 140 B | 81 / 80 | 1 333 / 4 828 B |
| 8.0.0 gekürzt | 22 044 B | 81 / 15 Themen-Absätze | 664 / 1 045 B (mit Überschrift); Absatz allein max. 895 B |
| 7.0.0 | 33 709 B | 16 | 1 789 / 3 555 B |
| 6.1.0 | 24 758 B | 8 | 3 091 / 4 057 B |
| 5.0.0 | 100 045 B | (vor dem Schichtmodell) | – |
- `instructions/dev/version-parts.md` verlangte „a few sentences“ pro Changeset. Das wurde systematisch überschritten und von nichts geprüft. Selbst bei eingehaltenen ~500 B ergäben 80 Bumps 40 KB. Eine reine Längenvorgabe pro Changeset hätte das Problem also nicht gelöst.
- Ein Bump mit Migrationsdokument hinterließ keine Zeile im Eintrag, und `docs verify` akzeptierte das Dokument stillschweigend. 5.0.0 hat seinen Verweis von Hand in den Breaking-Text geschrieben.
- `version-parts.md` behauptete, Bump-Titel und `###`-Überschrift seien „the same string“. Der gekürzte 8.0.0 hielt das nicht ein, und nichts prüfte es.
- Die Einleitung von `CHANGES.md` (~4 KB) beschrieb das Format ein zweites Mal – Invariante 8.
- `release.yml` verweigert ab 60 000 Bytes (#183). Das greift aber erst nach dem Fixieren des Kandidaten.
- `CHANGES.md` wird nicht ausgeliefert. Eine Instanz hat keinen versionierten Eintrag, also sind die neuen Prüfungen dort wirkungslos.
## Entscheidungen
- **F1 – Absatz oder Stichpunkt: Urteil der Build-Sitzung** (Betreiber, 2026-10-06). Es gibt keine Kopplung an `--impact`. Absätze sind thematisch und bündeln mehrere Bumps; eine Zuordnung Bump → Absatz ließe sich nicht prüfen. Mechanisch geprüft wird nur das Budget.
- **F2 – Budget** (Betreiber, 2026-10-06): Der oberste versionierte Eintrag hat höchstens **32 000 Bytes** (UTF-8, gemessen an der Ausgabe von `version notes`, halbe Gitea-Grenze). Jeder `###`-Abschnitt ist **genau ein Absatz** (keine Leerzeile im Rumpf) mit höchstens **1 000 Bytes**, ohne `###`-Zeile. Der Rumpf reicht bis zur nächsten `### `- oder `## `-Zeile bzw. bis zu `---`; Leerzeilen an den Rändern zählen nicht. Geprüft wird in `docs verify` und in `version release` vor dem Schreiben. Der Betreiber wählte 1 000 statt 1 500 Bytes. Gemessen wird ohne Überschrift, damit der gekürzte 8.0.0 besteht (1 045 B mit, 895 B ohne).
- **F3 – Ältere Einträge bleiben unverändert** (Betreiber, 2026-10-06). Beide Prüfungen gelten nur für den obersten versionierten Eintrag.
## Umsetzung
1. **Eintragsform** in `instructions/dev/version-parts.md` § The candidate model (Schichten 1–4 und ein neuer Budget-Absatz), Schritt 6 (Rücknahme von `--no-migration`) und Schritt 8. Die Bump-Liste ist die Stichpunktebene. `###`-Abschnitte gibt es pro Thema statt pro Bump, je ein Absatz im Budget; ein weiterer Bump zum selben Thema schreibt den vorhandenen Absatz um. „same string“ ist entfallen.
2. **Migrationsverweis, mechanisch** (`version.py`: `MIGRATION_MARKER`, `MIGRATION_REQUIRED_MARKER`, `migration_required_line`, `migration_paths`, `_record_migration`; `version_cmd.bump_command`):
- Zielt ein erforderliches Migrationsdokument auf die Basis des Kandidaten, schreibt jeder `version bump` die Zeile `**Migration:** required - instructions/migrations/<datei>.md`, mehrere Pfade sortiert und kommagetrennt, am Anker der `none required`-Zeile. Die beiden Formen schließen sich aus.
- `--migration-required` ersetzt `none required` durch die `required`-Zeile.
- `docs verify` hat die neue Prüfung `check_migration_line_names_documents`: Ein grenzüberschreitender oberster Eintrag muss jedes auf ihn zielende erforderliche Dokument nennen.
- **Beim Bau präzisiert**, ohne die Entscheidungen zu berühren:
- Nur `obligation: required` zählt. Ein `offered`-Dokument darf eine Instanz ablehnen; 6.0.0 hatte so eines neben einer korrekten `none required`-Zeile.
- `--no-migration` wird verweigert, solange ein erforderliches Dokument auf die Basis zielt.
- Eine verwaiste `required`-Zeile fällt beim nächsten Bump weg.
3. **Budgetprüfung:** `version.budget_issues` mit `ENTRY_MAX_BYTES = 32_000` und `CHANGESET_MAX_BYTES = 1_000`, dazu `docs_verify.check_changelog_budget`. `version release` prüft den Eintrag so, wie er nach dem Release aussähe (auch mit `--title` und `--dry-run`). Bei Überschreitung gibt es ERROR und Exit 1, der Abschnitt und seine Größe werden genannt, und nichts wird geschrieben.
4. **`CHANGES.md`-Einleitung** auf zwei Absätze gekürzt, mit Verweis auf `version-parts.md`. Die Einträge sind unberührt.
5. **Doku-Nachzug:**
- `DEVELOPMENT.md` Schritte 2, 4 und 6; `stack-build` Schritt 4; `instructions/migrate-corpus.md`.
- `cli_contract`-Datensätze von `version bump`, `version release` und `docs verify`. Der `docs verify`-Datensatz nannte seine Versions- und Changelog-Prüfungen vorher gar nicht.
- Docstrings; `tools/CONTRACT.md` regeneriert.
- In `stack-close`: die Abschlussmeldung von `version bump` (`0e15972`).
- Geprüft und unverändert: `docs/version-model.md`, `README.md`, `tools/README.md`, `INSTALL.md`. Sie machen keine Aussage über die Form eines Eintrags. Eine `docs/`-Seite fürs Budget braucht es nicht, weil die Regel nur im Ursprungs-Repo greift.
## Akzeptanzkriterien
- [x] `docs verify` meldet einen obersten Eintrag über 32 000 Bytes. Test: `test_an_entry_over_32000_bytes_is_reported`.
- [x] `docs verify` meldet einen `###`-Abschnitt mit mehr als einem Absatz und einen, dessen Absatz über 1 000 Bytes liegt; genau 1 000 Bytes bestehen. Tests: `test_a_section_with_two_paragraphs_is_reported`, `test_a_paragraph_over_1000_bytes_is_reported_in_bytes_not_characters`, `test_a_paragraph_of_exactly_1000_bytes_passes_and_its_heading_is_not_counted`.
- [x] Ein älterer Eintrag über beiden Grenzen löst keine Meldung aus. Test: `test_an_older_entry_over_both_limits_is_not_reported`.
- [x] `docs verify` ist grün. Der gekürzte 8.0.0-Eintrag bestand (22 043 B, Absatz max. 895 B), danach der neue 8.1.0-beta-Eintrag (`test_this_repos_newest_changelog_entry_is_inside_its_budget`).
- [x] `version bump` mit erforderlichem Dokument hinterlässt genau eine `required`-Zeile; ein zweiter Bump lässt sie byte-gleich. Test: `test_bump_names_a_required_migration_document_and_a_second_bump_keeps_it`.
- [x] `--migration-required` hinterlässt die `required`-Zeile mit dem Pfad. Test: `test_migration_required_retracts_the_no_migration_line`.
- [x] `docs verify` meldet einen grenzüberschreitenden Eintrag ohne Verweis auf sein erforderliches Dokument. Test: `test_a_crossing_entry_that_does_not_name_its_migration_document_is_reported`.
- [x] `version release` verweigert über dem Budget mit Exit 1; `VERSION` und `CHANGES.md` bleiben byte-gleich. Test: `test_release_refuses_an_entry_over_budget_and_writes_nothing` (drei Fälle).
- [x] Die Formregeln stehen nur in `version-parts.md`, die anderen Dokumente verweisen darauf. „same string“ steht nirgends mehr.
- [x] `pytest` (2352 passed, 3 skipped), `docs verify` und `instructions verify` sind grün. CI ist grün auf `044943a` (Läufe 572, 573) und `0e15972` (Läufe 574, 575).
## Versions-Teil
**`--minor`**, `--impact medium` → `8.1.0-beta.1`; der Nachzug kam als `--patch` mit `--impact low` → `8.1.0-beta.2`. Drop-in in beide Richtungen: Eine Instanz hat keinen versionierten Eintrag, und eine alte Version liest die neue Migrationszeile ohne Fehler. Kein Kommando und kein Flag ist entfallen. Der 8.1.0-Eintrag ist der erste in der neuen Form.
## Nicht im Umfang
- Die 60 000-Byte-Sperre in `release.yml` bleibt als letztes Netz (#183).
- Ältere Einträge werden nicht gekürzt (F3).
- Die Bump-Liste bleibt vollständig und maschinell. Bumps zusammenzulegen bräuchte einen neuen Schreibweg in die maschinenverwaltete Region (Invariante 1); das Gesamtbudget deckt den Fall ab.
- Die Sprachmischung der Bump-Titel (EN/DE) ist ein eigenes Thema, falls gewünscht.
torben
changed title from Changelog insgesamt kompakter: Einträge, Changesets und Release-Notizen to Changelog-Einträge kompakt halten: Absatz pro Thema statt Changeset pro Bump, Größenbudget, Migrationsverweis2026-10-06 12:50:11 +00:00
Changelog: Stub ausgearbeitet und gegen den Baum geprüft. Der Body enthält jetzt Befund mit Messwerten, Vorschlag, die drei offenen Fragen F1–F3, vorläufige Akzeptanzkriterien und den Versions-Teil (--minor). Labels: status/incoming entfernt; kind/decision, prio/planned (der nächste Kandidat wächst ab jetzt), size/M. Titel präzisiert.
Ursprünglicher Stub, wörtlich:
Stub vom Betreiber, im Release-Gespräch zu 8.0.0 angelegt (wörtlich):
128 kB ist viel zu lang, da müssen wir insgesamt kompakter werden. lege dafür einen incoming issue an, das regeln wir getrennt.
Dampfe das aktuelle Changelog massiv ein: Breaking Changes, ggf mit Verweis/Listing der notwendigen Migrationen, größere Änderungen mit einem Absatz, kleinere mit einem Stichpunkt
Anlass: Der 8.0.0-Eintrag in CHANGES.md hatte 129 KB (81 Bumps, 80 ###-Changesets) und scheiterte als Release-Notiz an der Argumentgrenze und an Giteas MySQL-Grenze von 65 535 Bytes. Der Eintrag selbst wurde für das Release von Hand auf 22 KB gekürzt (#183); dieser Stub betrifft, wie Einträge künftig von vornherein kompakt bleiben.
Titel vorher: „Changelog insgesamt kompakter: Einträge, Changesets und Release-Notizen“.
**Changelog:** Stub ausgearbeitet und gegen den Baum geprüft. Der Body enthält jetzt Befund mit Messwerten, Vorschlag, die drei offenen Fragen F1–F3, vorläufige Akzeptanzkriterien und den Versions-Teil (`--minor`). Labels: `status/incoming` entfernt; `kind/decision`, `prio/planned` (der nächste Kandidat wächst ab jetzt), `size/M`. Titel präzisiert.
Ursprünglicher Stub, wörtlich:
> Stub vom Betreiber, im Release-Gespräch zu 8.0.0 angelegt (wörtlich):
>
> > 128 kB ist viel zu lang, da müssen wir insgesamt kompakter werden. lege dafür einen incoming issue an, das regeln wir getrennt.
> > Dampfe das aktuelle Changelog massiv ein: Breaking Changes, ggf mit Verweis/Listing der notwendigen Migrationen, größere Änderungen mit einem Absatz, kleinere mit einem Stichpunkt
>
> Anlass: Der 8.0.0-Eintrag in `CHANGES.md` hatte 129 KB (81 Bumps, 80 `###`-Changesets) und scheiterte als Release-Notiz an der Argumentgrenze und an Giteas MySQL-Grenze von 65 535 Bytes. Der Eintrag selbst wurde für das Release von Hand auf 22 KB gekürzt (#183); dieser Stub betrifft, wie Einträge künftig von vornherein kompakt bleiben.
Titel vorher: „Changelog insgesamt kompakter: Einträge, Changesets und Release-Notizen“.
F1: Absatz oder Stichpunkt entscheidet die Build-Sitzung.
F2: Eintrag höchstens 32 000 B. Absatz höchstens 1 000 B statt der vorgeschlagenen 1 500 B, gemessen ohne ###-Überschrift, damit der gekürzte 8.0.0 (Absatz max. 895 B) besteht.
F3: Alte Einträge bleiben unverändert.
Die offenen Fragen sind durch einen Abschnitt „Entscheidungen“ ersetzt. Umsetzung und Akzeptanzkriterien sind konkretisiert: Messregel des Rumpfs, Grenzfall genau 1 000 B, älterer Eintrag ohne Meldung, release lässt bei Verweigerung alles byte-gleich. kind/decision → kind/build.
**Changelog:** F1–F3 entschieden:
- F1: Absatz oder Stichpunkt entscheidet die Build-Sitzung.
- F2: Eintrag höchstens 32 000 B. Absatz höchstens 1 000 B statt der vorgeschlagenen 1 500 B, gemessen ohne `###`-Überschrift, damit der gekürzte 8.0.0 (Absatz max. 895 B) besteht.
- F3: Alte Einträge bleiben unverändert.
Die offenen Fragen sind durch einen Abschnitt „Entscheidungen“ ersetzt. Umsetzung und Akzeptanzkriterien sind konkretisiert: Messregel des Rumpfs, Grenzfall genau 1 000 B, älterer Eintrag ohne Meldung, `release` lässt bei Verweigerung alles byte-gleich. `kind/decision` → `kind/build`.
Changelog: Gebaut und gepublisht als 8.1.0-beta.1 (044943a), CI grün (Läufe 572, 573). Alle Akzeptanzkriterien sind abgehakt und nennen ihre Tests. Neuer Abschnitt „Stand“. In Umsetzung 2 und 3 steht, was beim Bau präzisiert wurde: Nur obligation: required löst die required-Zeile aus. --no-migration wird neben einem erforderlichen Dokument verweigert. Eine verwaiste required-Zeile fällt beim nächsten Bump weg. release prüft das Budget am Eintrag, wie er nach dem Release aussähe. Zusätzlich im Doku-Nachzug: migrate-corpus.md und der docs verify-Datensatz, der seine Versions- und Changelog-Prüfungen vorher gar nicht nannte.
**Changelog:** Gebaut und gepublisht als `8.1.0-beta.1` (`044943a`), CI grün (Läufe 572, 573). Alle Akzeptanzkriterien sind abgehakt und nennen ihre Tests. Neuer Abschnitt „Stand“. In Umsetzung 2 und 3 steht, was beim Bau präzisiert wurde: Nur `obligation: required` löst die `required`-Zeile aus. `--no-migration` wird neben einem erforderlichen Dokument verweigert. Eine verwaiste `required`-Zeile fällt beim nächsten Bump weg. `release` prüft das Budget am Eintrag, wie er nach dem Release aussähe. Zusätzlich im Doku-Nachzug: `migrate-corpus.md` und der `docs verify`-Datensatz, der seine Versions- und Changelog-Prüfungen vorher gar nicht nannte.
Changelog: Abschluss. Body in den Endzustand gebracht: „Stand“ nennt beide Commits und ihre CI-Läufe, der Befund steht in der Vergangenheit, und der Doku-Nachzug nennt die geprüften, unveränderten Dokumente. Nachzug aus stack-close: Die Abschlussmeldung von version bump verlangte pauschal Prosa. Das ist behoben in 8.1.0-beta.2 (0e15972), CI grün (Läufe 574, 575). Geschlossen.
**Changelog:** Abschluss. Body in den Endzustand gebracht: „Stand“ nennt beide Commits und ihre CI-Läufe, der Befund steht in der Vergangenheit, und der Doku-Nachzug nennt die geprüften, unveränderten Dokumente. Nachzug aus `stack-close`: Die Abschlussmeldung von `version bump` verlangte pauschal Prosa. Das ist behoben in `8.1.0-beta.2` (`0e15972`), CI grün (Läufe 574, 575). Geschlossen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Stand
Erledigt (2026-10-06). Ausgeliefert im Kandidaten
8.1.0(noch nicht released):8.1.0-beta.1, Commit044943a: Umsetzung 1–5. CI grün: Läufe 572 (verify,pwsh) und 573.8.1.0-beta.2, Commit0e15972: Nachzug ausstack-close. Die Abschlussmeldung vonversion bumpverlangte noch pauschal „write its prose“ und nennt jetzt Stichpunkt oder Themenabsatz. CI grün: Läufe 574 und 575.Anlass
Der 8.0.0-Eintrag in
CHANGES.mdhatte 129 KB und scheiterte als Release-Notiz an Linux' Argumentgrenze und an Giteas MySQL-Grenze von 65 535 Bytes (#183). Er wurde für das Release von Hand auf 22 KB gekürzt. Dieses Issue regelt, dass Einträge von vornherein kompakt bleiben, statt am Release-Tag gekürzt zu werden. Der ursprüngliche Stub steht wörtlich im ersten Kommentar.Zielform laut Betreiber: Breaking Changes, ggf. mit Verweis/Listing der nötigen Migrationen; größere Änderungen mit einem Absatz; kleinere mit einem Stichpunkt. Der gekürzte 8.0.0-Eintrag (
2ddcd6b) ist das Referenzbeispiel dieser Form.Befund (vor dem Bau, gegen den Baum geprüft, 2026-10-06)
Ursache war das Modell „ein
###-Changeset pro Bump“, nicht einzelne zu lange Texte. Ein Eintrag wuchs linear mit der Zahl der Bumps, und ein Kandidat sammelt Bumps über Wochen:instructions/dev/version-parts.mdverlangte „a few sentences“ pro Changeset. Das wurde systematisch überschritten und von nichts geprüft. Selbst bei eingehaltenen ~500 B ergäben 80 Bumps 40 KB. Eine reine Längenvorgabe pro Changeset hätte das Problem also nicht gelöst.docs verifyakzeptierte das Dokument stillschweigend. 5.0.0 hat seinen Verweis von Hand in den Breaking-Text geschrieben.version-parts.mdbehauptete, Bump-Titel und###-Überschrift seien „the same string“. Der gekürzte 8.0.0 hielt das nicht ein, und nichts prüfte es.CHANGES.md(~4 KB) beschrieb das Format ein zweites Mal – Invariante 8.release.ymlverweigert ab 60 000 Bytes (#183). Das greift aber erst nach dem Fixieren des Kandidaten.CHANGES.mdwird nicht ausgeliefert. Eine Instanz hat keinen versionierten Eintrag, also sind die neuen Prüfungen dort wirkungslos.Entscheidungen
--impact. Absätze sind thematisch und bündeln mehrere Bumps; eine Zuordnung Bump → Absatz ließe sich nicht prüfen. Mechanisch geprüft wird nur das Budget.version notes, halbe Gitea-Grenze). Jeder###-Abschnitt ist genau ein Absatz (keine Leerzeile im Rumpf) mit höchstens 1 000 Bytes, ohne###-Zeile. Der Rumpf reicht bis zur nächsten###- oder##-Zeile bzw. bis zu---; Leerzeilen an den Rändern zählen nicht. Geprüft wird indocs verifyund inversion releasevor dem Schreiben. Der Betreiber wählte 1 000 statt 1 500 Bytes. Gemessen wird ohne Überschrift, damit der gekürzte 8.0.0 besteht (1 045 B mit, 895 B ohne).Umsetzung
instructions/dev/version-parts.md§ The candidate model (Schichten 1–4 und ein neuer Budget-Absatz), Schritt 6 (Rücknahme von--no-migration) und Schritt 8. Die Bump-Liste ist die Stichpunktebene.###-Abschnitte gibt es pro Thema statt pro Bump, je ein Absatz im Budget; ein weiterer Bump zum selben Thema schreibt den vorhandenen Absatz um. „same string“ ist entfallen.version.py:MIGRATION_MARKER,MIGRATION_REQUIRED_MARKER,migration_required_line,migration_paths,_record_migration;version_cmd.bump_command):version bumpdie Zeile**Migration:** required - instructions/migrations/<datei>.md, mehrere Pfade sortiert und kommagetrennt, am Anker dernone required-Zeile. Die beiden Formen schließen sich aus.--migration-requiredersetztnone requireddurch dierequired-Zeile.docs verifyhat die neue Prüfungcheck_migration_line_names_documents: Ein grenzüberschreitender oberster Eintrag muss jedes auf ihn zielende erforderliche Dokument nennen.obligation: requiredzählt. Einoffered-Dokument darf eine Instanz ablehnen; 6.0.0 hatte so eines neben einer korrektennone required-Zeile.--no-migrationwird verweigert, solange ein erforderliches Dokument auf die Basis zielt.required-Zeile fällt beim nächsten Bump weg.version.budget_issuesmitENTRY_MAX_BYTES = 32_000undCHANGESET_MAX_BYTES = 1_000, dazudocs_verify.check_changelog_budget.version releaseprüft den Eintrag so, wie er nach dem Release aussähe (auch mit--titleund--dry-run). Bei Überschreitung gibt es ERROR und Exit 1, der Abschnitt und seine Größe werden genannt, und nichts wird geschrieben.CHANGES.md-Einleitung auf zwei Absätze gekürzt, mit Verweis aufversion-parts.md. Die Einträge sind unberührt.DEVELOPMENT.mdSchritte 2, 4 und 6;stack-buildSchritt 4;instructions/migrate-corpus.md.cli_contract-Datensätze vonversion bump,version releaseunddocs verify. Derdocs verify-Datensatz nannte seine Versions- und Changelog-Prüfungen vorher gar nicht.tools/CONTRACT.mdregeneriert.stack-close: die Abschlussmeldung vonversion bump(0e15972).docs/version-model.md,README.md,tools/README.md,INSTALL.md. Sie machen keine Aussage über die Form eines Eintrags. Einedocs/-Seite fürs Budget braucht es nicht, weil die Regel nur im Ursprungs-Repo greift.Akzeptanzkriterien
docs verifymeldet einen obersten Eintrag über 32 000 Bytes. Test:test_an_entry_over_32000_bytes_is_reported.docs verifymeldet einen###-Abschnitt mit mehr als einem Absatz und einen, dessen Absatz über 1 000 Bytes liegt; genau 1 000 Bytes bestehen. Tests:test_a_section_with_two_paragraphs_is_reported,test_a_paragraph_over_1000_bytes_is_reported_in_bytes_not_characters,test_a_paragraph_of_exactly_1000_bytes_passes_and_its_heading_is_not_counted.test_an_older_entry_over_both_limits_is_not_reported.docs verifyist grün. Der gekürzte 8.0.0-Eintrag bestand (22 043 B, Absatz max. 895 B), danach der neue 8.1.0-beta-Eintrag (test_this_repos_newest_changelog_entry_is_inside_its_budget).version bumpmit erforderlichem Dokument hinterlässt genau einerequired-Zeile; ein zweiter Bump lässt sie byte-gleich. Test:test_bump_names_a_required_migration_document_and_a_second_bump_keeps_it.--migration-requiredhinterlässt dierequired-Zeile mit dem Pfad. Test:test_migration_required_retracts_the_no_migration_line.docs verifymeldet einen grenzüberschreitenden Eintrag ohne Verweis auf sein erforderliches Dokument. Test:test_a_crossing_entry_that_does_not_name_its_migration_document_is_reported.version releaseverweigert über dem Budget mit Exit 1;VERSIONundCHANGES.mdbleiben byte-gleich. Test:test_release_refuses_an_entry_over_budget_and_writes_nothing(drei Fälle).version-parts.md, die anderen Dokumente verweisen darauf. „same string“ steht nirgends mehr.pytest(2352 passed, 3 skipped),docs verifyundinstructions verifysind grün. CI ist grün auf044943a(Läufe 572, 573) und0e15972(Läufe 574, 575).Versions-Teil
--minor,--impact medium→8.1.0-beta.1; der Nachzug kam als--patchmit--impact low→8.1.0-beta.2. Drop-in in beide Richtungen: Eine Instanz hat keinen versionierten Eintrag, und eine alte Version liest die neue Migrationszeile ohne Fehler. Kein Kommando und kein Flag ist entfallen. Der 8.1.0-Eintrag ist der erste in der neuen Form.Nicht im Umfang
release.ymlbleibt als letztes Netz (#183).Changelog insgesamt kompakter: Einträge, Changesets und Release-Notizento Changelog-Einträge kompakt halten: Absatz pro Thema statt Changeset pro Bump, Größenbudget, MigrationsverweisChangelog: Stub ausgearbeitet und gegen den Baum geprüft. Der Body enthält jetzt Befund mit Messwerten, Vorschlag, die drei offenen Fragen F1–F3, vorläufige Akzeptanzkriterien und den Versions-Teil (
--minor). Labels:status/incomingentfernt;kind/decision,prio/planned(der nächste Kandidat wächst ab jetzt),size/M. Titel präzisiert.Ursprünglicher Stub, wörtlich:
Titel vorher: „Changelog insgesamt kompakter: Einträge, Changesets und Release-Notizen“.
Changelog: F1–F3 entschieden:
###-Überschrift, damit der gekürzte 8.0.0 (Absatz max. 895 B) besteht.Die offenen Fragen sind durch einen Abschnitt „Entscheidungen“ ersetzt. Umsetzung und Akzeptanzkriterien sind konkretisiert: Messregel des Rumpfs, Grenzfall genau 1 000 B, älterer Eintrag ohne Meldung,
releaselässt bei Verweigerung alles byte-gleich.kind/decision→kind/build.Changelog: Gebaut und gepublisht als
8.1.0-beta.1(044943a), CI grün (Läufe 572, 573). Alle Akzeptanzkriterien sind abgehakt und nennen ihre Tests. Neuer Abschnitt „Stand“. In Umsetzung 2 und 3 steht, was beim Bau präzisiert wurde: Nurobligation: requiredlöst dierequired-Zeile aus.--no-migrationwird neben einem erforderlichen Dokument verweigert. Eine verwaisterequired-Zeile fällt beim nächsten Bump weg.releaseprüft das Budget am Eintrag, wie er nach dem Release aussähe. Zusätzlich im Doku-Nachzug:migrate-corpus.mdund derdocs verify-Datensatz, der seine Versions- und Changelog-Prüfungen vorher gar nicht nannte.Changelog: Abschluss. Body in den Endzustand gebracht: „Stand“ nennt beide Commits und ihre CI-Läufe, der Befund steht in der Vergangenheit, und der Doku-Nachzug nennt die geprüften, unveränderten Dokumente. Nachzug aus
stack-close: Die Abschlussmeldung vonversion bumpverlangte pauschal Prosa. Das ist behoben in8.1.0-beta.2(0e15972), CI grün (Läufe 574, 575). Geschlossen.