semver-und-releaseslisted

# Versionierung und Releases ## Semantic Versioning `MAJOR.MINOR.PATCH` nach <https://semver.org/>. | Teil | steigt bei | wer | |---|---|---| | **MAJOR** | Bruch der Kompatibilität | **nur der Nutzer** | | **MINOR** | neue Funktion, abwärtskompatibel | Claude | | **PATCH** | Fehlerbehebung, abwärtskompatibel | Claude | MINOR setzt PATCH auf 0, MAJOR setzt beide auf 0. **Vor dem ersten Release** läuft die Entwicklung ab `0.1.0`. In `0.x` gilt keine Kompatibilitätszusage; neue Funktionen erhöhen MINOR, Korrekturen PATCH. **Das erste Release ist immer `1.0.0`** — nie `0.x` als Release veröffentlichen. Steigt aus deiner Sicht MAJOR an, ist das keine Entscheidung, die du triffst: sag es und begründe, woran du den Bruch festmachst. ## Wo die Version steht Genau eine Quelle je Projekt. Gibt es keine natürliche (etwa `package.json`, `pyproject.toml`, `*.csproj`), dann eine Datei `VERSION` im Wurzelverzeichnis mit der nackten Nummer und einem Zeilenumbruch. Muss die Nummer an weiteren Stellen auftauchen, wird sie von dort **abgeleitet**, nicht abgeschrieben. Eine zweite gepflegte Fassung läuft auseinander — die Frage ist nur, wann. **Wenn das Format zwei Fassungen erzwingt**, wie bei einem Claude-Plugin (`.claude-plugin/marketplace.json` und `plugins/<name>/.claude-plugin/plugin.json`), gilt die Ausnahme nur mit einer **Prüfung, die den Gleichlauf erzwingt** — hier `claude plugin tag`, das das Release verweigert, wenn beide auseinanderliegen. Ohne solche Prüfung ist die zwei