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