Versioning

Die Versionierung von Celestia folgt dem Prinzip der semantischen Versionierung (SemVer). Sie ermöglicht vorhersehbare Updates, klare Kommunikation von Änderungen und kontrollierte Migrationen.

Semantische Versionierung (SemVer)

Format: MAJOR.MINOR.PATCH

Beispiel: 2.4.1

• MAJOR (2): Breaking Changes
• MINOR (4): Neue Features (rückwärtskompatibel)
• PATCH (1): Bugfixes (rückwärtskompatibel)

Wann welche Version?

MAJOR (X.0.0):

• API-Änderungen, die bestehenden Code brechen
• Entfernung veralteter Features
• Signifikante Architektur-Änderungen
• Änderungen an Design Tokens, die visuelle Breaking Changes verursachen

MINOR (x.X.0):

• Neue Features
• Neue Komponenten
• Erweiterungen bestehender APIs
• Neue Design Token-Kategorien

PATCH (x.x.X):

• Bugfixes
• Performance-Optimierungen
• Dokumentations-Updates
• Security-Patches

Breaking Changes

Ein Breaking Change ist jede Änderung, die bestehende Arbeit im Code oder im Design-File “kaputt” macht und manuelles Nachbessern erfordert.

1. Was geht kaputt?

• Struktur: Umbenennen oder Löschen von Komponenten-Eigenschaften (Props/Varianten).
• Tokens: Umbenennen oder Entfernen von Design-Entscheidungen (Farben, Spacing, Typo).
• Logik: Grundlegende Änderung des Standardverhaltens einer Komponente.
• Visuals: Radikale Änderungen am HTML/CSS, die bestehende Layouts zerschießen.

2. Der Deprecation-Pfad

Wir löschen nichts sofort. Wir geben allen Zeit, Designs und Code anzupassen.

Schritt 1: Markierung (Release N)

• Design: Komponente in Figma mit einem “Deprecated” Tag versehen.
• Code: console.warn() hinzufügen und Alternativen benennen.
• Ziel: Nutzer wissen lassen: “Das hier verschwindet bald.”

Schritt 2: Schonfrist (Release N bis N+2)

• Design & Code: Alles funktioniert noch wie gewohnt, wird aber in der Suche/Library nach unten verschoben.
• Support: Wir helfen Teams aktiv beim Umstieg auf die neue Version.

Schritt 3: Entfernung (Major Release)

• Design: Komponente wird aus der Main-Library gelöscht (bleibt im Archiv).
• Code: Feature wird endgültig entfernt.
• Doku: Ein klarer Migration-Guide zeigt den Vorher-Nachher-Vergleich.

3. Changelogs: Wer hat was gemacht?

Wir nutzen das “Keep a Changelog” Format, damit jeder sofort sieht, was relevant ist:

Struktur nach Keep a Changelog:

## [2.4.0] - 2025-03-15

### Added

- New component: DataTable
- New prop: Button now supports `isLoading` state
- New design tokens for shadows

### Changed

- Improved Button hover animation
- Updated Card padding values

### Deprecated

- Button `type` prop (use `variant` instead)

### Removed

- Nothing

### Fixed

- Fixed FocusTrap in Modal
- Fixed Safari rendering issue in Card

### Security

- Updated dependencies

3. Kommunikation (Synchronisation)

Änderungen bringen nichts, wenn keiner davon weiß. Wir kommunizieren über:

1. Slack/Teams: Kurze Alerts bei jedem Release.
2. Figma-Release-Notes: Direkt im “Description”-Feld der Library-Updates.
3. Migration-Guides: Schritt-für-Schritt-Anleitungen für große Umstellungen.

Tipp für Designer: Nutzt die “Description” in Figma-Komponenten, um den Link zum Changelog zu hinterlegen. So sehen Devs und Designer sofort, was Sache ist.

Versions-Übersicht

In der Dokumentation:

• Aktuelle Version prominent anzeigen
• Versions-Historie
• Support-Status pro Version
• Upgrade-Pfade

---

Semantische Versionierung ermöglicht vertrauensvolle Updates und klare Erwartungen. Sie ist das Fundament für stabile und wartbare Produkte.