chemenu/kb/sources/transcripts/Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02.md

type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary, fidelity, authority

type	source_type	author	raw_files	source_language	date	tags	entities	concepts	summary	fidelity	authority
types/source.md	transcript	Torben Nehmer	raw/notes/Conversation Transcript - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02.md	de	2026-09-02		wikitool Chemenu	KB Stack Versioning	Sitzung, die die Versionsstelle als Kompatibilitaets- statt Migrationsfrage praezisiert und einen Freigabe-Ablauf fuer Breaking Changes in stack-dev einfuehrt	verbatim	reporting

Source: Version Part Nomenclature and Breaking Change Gate Session 2026-09-02

Autor: Torben Nehmer
Datum: 2026-09-02
Raw-Dateien: raw/notes/Conversation Transcript - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02.md
Typ: Notes

Zusammenfassung

Umsetzung von Gitea-Issue #26: Die Doku des Stacks führte für die Wahl der Versionsstelle zwei Fragen zusammen, die nicht dieselbe sind - ob der Korpus migriert werden muss, und ob der Wechsel ein Drop-in-Ersatz ist. Nur version bump --help unterschied korrekt; die drei prosaischen Stellen (stack-dev, version.py-Docstring, INSTALL.md) beschrieben MAJOR als Migrationsfrage. Der 2.0.0-Rebranding-Bump hatte genau daran zuerst 1.9.0 statt --major angesetzt.

Der Nutzer schärfte die Regel während der Sitzung zu einem konkreten zweiseitigen Test nach: "die neue version ist kein drop-in replacement. Sobald irgendwie Hand angelegt werden muss, sei es durch den user oder durch ein Migrationsscript, ist es ein major version change. selbiges gilt, wenn ein update nicht rückgängig gemacht werden kann [...] in allen Fällen muss bei einem Major version change ein 'Breaking Change' vermerkt werden. breaking changes sind damit teuer. passe stack-dev so an, dass in diesen Fällen zwingend der user informiert, Alternativen aufgezeigt und eine freigabe eingeholt wird." Zwei Auswahlentscheidungen davor: Durchsetzung im Code statt reiner Prosa (weil Prosa bereits einmal gedriftet war), und die Freigabe als "Decision point" statt als Gate-Sprache, um die drei echten code-erzwungenen Gates nicht zu verwässern.

Kernaussagen

• Kompatibilität (Drop-in-Ersatz, vorwärts wie rückwärts) und Inhaltsmigration sind zwei unabhängige Fragen; MAJOR beantwortet die erste, --no-migration/ein Migrationsdokument die zweite.
• Ein Grenzübertritt kann kb/ völlig unangetastet lassen und trotzdem MAJOR sein - Katalog: Update-Pfad, Release-Artefaktname, Paket-Import-Name, ein umbenanntes Kommando/Flag/Envvar, die Shape einer maschinengelesenen Datei.
• Ein Breaking Change ist teuer (jede bestehende Instanz zahlt einmal, von Hand) und deshalb genehmigungspflichtig: Bruch, Handarbeit je Instanz und Alternativen (Shim, aufschieben und bündeln, aufspalten mit Deprecation-Fenster) vorlegen, dann Freigabe abwarten.
• Reine Prosa-Regeln drifted - deshalb wurde --breaking als Pflichtflag samt zweiter, von der Migrationsprüfung unabhängiger docs verify-Prüfung eingeführt, nicht nur eine Textänderung.

Aufgaben

Keine offenen Aufgaben aus dieser Sitzung - Issue #26 wurde in derselben Sitzung geschlossen, mit Verweis auf Commit 31662dc (2.5.0).

Nicht übernommen

• Die vollständige Katalog-Tabelle und der 2.0.0-Fallbeispiel-Text aus instructions/dev/version-parts.md werden hier nicht wiederholt - die Datei ist die autoritative Quelle (Instruktions-Layer, manual-artig durch die instructions/dev/-Grenze), diese Source-Seite fasst nur zusammen, was zur Entscheidung führte.
• Der genaue Wortlaut der Tool-Fehlermeldungen (version bump-Refusals) steht im Transkript selbst; hier nur die Regel dahinter.

Verwandte Entities

• wikitool
• Chemenu

Verwandte Concepts

• KB Stack Versioning