Ein Release ist eine abgeschlossene, veröffentlichte Version einer Software — der Punkt, an dem ein definierter Funktionsumfang für Nutzer oder Kundschaft freigegeben wird. Release-Management umfasst Planung, Qualitätssicherung, Freigabe und Dokumentation dieser Versionen.

Release-Arten

  • Major Release: Neue Hauptversion mit inkompatiblen Änderungen (z.B. Version 2.0).
  • Minor Release: Neue Funktionen, abwärtskompatibel (z.B. Version 2.1).
  • Patch Release: Fehlerbehebungen und Sicherheitsupdates (z.B. Version 2.1.3).
  • Release Candidate (RC): Kandidat für die finale Version, der noch getestet wird.
  • Nightly/Snapshot: Tägliche Zwischenstände aus der Entwicklung.

Die Benennung folgt meist der semantischen Versionierung (MAJOR.MINOR.PATCH).

Release-Prozess

  1. Planung: Features und Fixes für die Version festlegen (Release-Plan).
  2. Entwicklung: Änderungen in Branches umsetzen und in den Hauptzweig mergen.
  3. Qualitätssicherung: Tests, Code-Review und Abnahmeprüfungen.
  4. Freigabe: Verantwortliche geben die Version offiziell frei (Go-Live).
  5. Ausrollung: Das Deployment bringt die Version in die Zielumgebung.
  6. Dokumentation: Changelog und Release-Notes beschreiben die Änderungen.

Release-Notes und Changelog

Ein Changelog listet chronologisch alle Änderungen pro Version auf. Gute Einträge sind nach Bedeutung sortiert: neue Features zuerst, dann Verbesserungen, dann Fehlerbehebungen, dann Sicherheitsupdates. So können Nutzer und Team schnell erkennen, was sich mit einem Update ändert.

Release-Management im Team

Release-Management funktioniert nur mit klarer Struktur: Ein definierter Stand im Repository (per Tag markiert), eine nachvollziehbare Pipeline und ein Rollback-Plan. Werkzeuge wie GitHub Releases, GitLab Releases oder SemVer-konforme Tags machen Veröffentlichungen reproduzierbar.

Verwandt: CI/CD, Build, GitFlow.