Shop Projekt - Dokumentation
Richtlinien für die Versionshistorie
Um die Nachvollziehbarkeit von Änderungen für das gesamte Team zu gewährleisten, folgt dieses Projekt den Prinzipien von "Keep a Changelog" und nutzt Semantic Versioning (SemVer).
Allgemeine Prinzipien
Für Menschen geschrieben: Einträge müssen verständlich formuliert sein. Technische Roh-Commits (z.B. "fix typo" oder "merge branch") haben im Changelog nichts zu suchen.
Chronologische Reihenfolge: Neue Releases und Anpassungen stehen immer ganz oben.
Datumsangabe: Jede Version wird zwingend mit dem Release-Datum im ISO-Format (`JJJJ-MM-TT`) versehen.
Die 6 Standard-Kategorien
Änderungen innerhalb einer Version werden in Gruppen unterteilt. Verwende und trenne die Gruppen, die für die zu erfassenden Änderungen relevant sind:
| Kategorie | Bedeutung & Anwendung |
|---|---|
| Neu | Für komplett neue Features und Funktionen (z.B. neue Registrierung). |
| Geändert | Für Änderungen an bestehenden Funktionen (z.B. Router-Logik optimiert). |
| Veraltet | Ankündigung für Komponenten, die in kommenden Versionen entfernt werden. |
| Entfernt | Funktionen oder alte Module, die in dieser Version komplett gelöscht wurden. |
| Behoben | Für jeden behobenen Bug, Code-Fehler oder unerwartetes Systemverhalten. |
| Sicherheit | Kritische Updates, Schließen von Sicherheitslücken (z.B. SQL-Injections). |
Semantische Versionierung (SemVer)
Versionsnummern folgen dem Format `MAJOR.MINOR.PATCH` (z.B. `1.2.3`):
MAJOR (`1`.x.x): Inkompatible Änderungen am Core (Breaking Changes). Views oder APIs müssen angepasst werden.
MINOR (x.`2`.x): Abwärtskompatible neue Features oder größere Meilensteine (z.B. deine Stufen von 0.1 bis 0.16).
PATCH (x.x.`3`): Abwärtskompatible reine Bugfixes und Hotfixes.