Files
Orchestrator/.kiro/steering/changelog-versioning.md
T
ankn cfaf670100 Squashed 'bahn/wissensdatenbank/' content from commit 07a8196e
git-subtree-dir: bahn/wissensdatenbank
git-subtree-split: 07a8196e5f9e55d027f90485beb95f4006387669
2026-06-30 21:19:25 +02:00

2.2 KiB
Raw Blame History

Changelog & Versionierung (verbindlich)

Diese Regel steuert, wann und wie CHANGELOG.md und VERSION zu pflegen sind. Sie gilt fuer jede Code-/Config-/Doku-Aenderung in diesem Repo.

Single Source of Truth

  • VERSION (Repo-Root): genau eine Zeile, MAJOR.MINOR.PATCH (SemVer).
  • CHANGELOG.md (Repo-Root): Format „Keep a Changelog". Oben steht immer ein Abschnitt ## [Unreleased].
  • Die GitLab-Pages-Seite „Changelog" (changelog.html) wird aus CHANGELOG.md erzeugt; src/site.py zeigt die VERSION in der Navigation an. Beides wird beim Pages-Build automatisch aktuell es ist also keine HTML-Datei von Hand zu pflegen, nur CHANGELOG.md und VERSION.

Bei JEDER inhaltlichen Aenderung (vor dem Commit)

Trage einen kurzen, nutzerverstaendlichen Eintrag unter ## [Unreleased] ein, gruppiert in Added / Changed / Fixed (bei Bedarf Removed):

## [Unreleased]
### Added
- <was neu ist>
### Fixed
- <was korrigiert wurde>

Reine interne Nebensaechlichkeiten (Tippfehler in Kommentaren o.ae.) muessen nicht ins Changelog.

Beim Abschluss eines Merge Requests (Release schneiden)

Wenn ein MR gemergt werden soll und [Unreleased] Eintraege enthaelt:

  1. Version bestimmen (SemVer, ausgehend vom aktuellen VERSION):
    • MAJOR +1: inkompatible Aenderung an Datenmodell/Frontmatter/Output-Struktur (output/processed/<scope>/<domaene>), an Strategien-Semantik oder Pipeline-Verhalten.
    • MINOR +1: neue Strategie/Quelle/Funktion/Seite, abwaertskompatibel.
    • PATCH +1: Bugfix, Doku, kleine Korrektur.
  2. VERSION auf die neue Nummer setzen.
  3. In CHANGELOG.md den Block ## [Unreleased] in ## [X.Y.Z] - JJJJ-MM-TT umbenennen (Datum = heute) und einen neuen leeren ## [Unreleased] darueber anlegen.
  4. Commit-Message: chore(release): vX.Y.Z.

Hinweise

  • Im Zweifel die kleinere Erhoehung waehlen (lieber MINOR als MAJOR), aber inkompatible Aenderungen ehrlich als MAJOR markieren.
  • Den automatischen Daten-Commit des Bots (chore(data): ...) NICHT versionieren er aendert nur data/, nicht Code/Verhalten.
  • Wird die Output-/Frontmatter-Struktur geaendert, zusaetzlich .kiro/steering/architecture.md, README.md und Tests anpassen (siehe AGENTS.md).