Skip to content

RELEASE.md

Latest commit

 

History

History
245 lines (179 loc) · 4.35 KB

RELEASE.md

File metadata and controls

245 lines (179 loc) · 4.35 KB
Raw

WindowsBridge – Release-Guide

Anleitung für die Vorbereitung und Veröffentlichung neuer Versionen.

Version-Schema

WindowsBridge folgt Semantic Versioning:

  • Major: Kompatibilität-Bruch (z.B. 2.0.0)
  • Minor: Neue Features (z.B. 1.1.0)
  • Patch: Bugfixes (z.B. 1.0.1)

Pre-Release Checklist

1. Code-Qualität prüfen

# Syntax überprüfen
make lint

# Tests ausführen
make test

# Alle Tests müssen bestanden sein

2. Dokumentation aktualisieren

  • README.md überprüft
  • CHANGELOG.md aktualisiert
  • docs/ überprüft
  • Alle Beispiele funktionieren
  • Links korrekt

3. Version aktualisieren

# VERSION-Datei aktualisieren
echo "1.1.0" > VERSION

# Git-Tag erstellen
git tag -a v1.1.0 -m "Release version 1.1.0"

4. CHANGELOG.md aktualisieren

Format:

## [1.1.0] – 2026-01-25

### Added
- Neue Feature X
- Neue Feature Y

### Fixed
- Bug X behoben
- Bug Y behoben

### Changed
- Verhaltenänderung X

5. Finale Tests

# Kompletter Test-Run
make test

# System-spezifische Tests
make test-system
make test-wine
make test-gaming

# Installation testen
make install-minimal

Release Steps

1. Code Freeze

  • Keine neuen Features
  • Nur Bugfixes für kritische Probleme
  • Testing-Phase: 1 Woche

2. Release Branch erstellen

git checkout -b release/v1.1.0

3. Version & Docs finalisieren

# Version aktualisieren
echo "1.1.0" > VERSION

# CHANGELOG.md finalisieren
nano CHANGELOG.md

# Committen
git commit -am "chore: Release v1.1.0"

4. Tag erstellen

git tag -a v1.1.0 -m "Release version 1.1.0 - Major features and improvements"

# Tag verifizieren
git tag -l
git show v1.1.0

5. Zu Main mergen

git checkout main
git merge release/v1.1.0
git push origin main
git push origin v1.1.0

6. GitHub Release erstellen

  1. GitHub → Releases → Draft New Release
  2. Tag: v1.1.0
  3. Title: WindowsBridge v1.1.0
  4. Description: [Aus CHANGELOG.md kopieren]
  5. Binary attachments: .tar.gz erzeugen
  6. Release erstellen

Versionsverlauf

v1.0.0 (2026-01-24) ✅ RELEASED

  • Initial Release
  • Alle Core-Features implementiert
  • Vollständige Dokumentation
  • Production-Ready

v1.1.0 (Geplant)

  • Erweiterte GPU-Unterstützung
  • Performance-Optimierungen
  • UI-Verbesserungen
  • Weitere Tests

Post-Release

1. Community benachrichtigen

  • GitHub Discussions
  • Release Notes tweeten
  • Blog-Post (falls vorhanden)

2. Monitoring

  • Issue-Tracker beobachten
  • Community-Feedback sammeln
  • Hotfixes für kritische Bugs vorbereiten

3. Nächste Version planen

  • Milestone erstellen
  • Issues priorisieren
  • Team-Briefing

Hotfix-Prozess

Falls nach Release ein kritischer Bug gefunden wird:

# Hotfix-Branch erstellen
git checkout -b hotfix/v1.0.1

# Bug fixen
nano modules/wine_setup.sh

# Testen
make test

# Version aktualisieren
echo "1.0.1" > VERSION

# CHANGELOG aktualisieren
nano CHANGELOG.md

# Commit & Tag
git commit -am "fix: Critical bug in wine setup"
git tag -a v1.0.1 -m "Hotfix v1.0.1"

# Zu main & develop mergen
git checkout main
git merge hotfix/v1.0.1
git push origin main
git push origin v1.0.1

Distributio-Kanäle (Zukünftig)

Geplante Release-Kanäle:

  • GitHub Releases - Quellcode & Dokumentation
  • Flatpak - Für einfache Installation (geplant)
  • Snap - Weitere Distributionsmöglichkeit (geplant)
  • Debian/Ubuntu PPA - Native Paketierung (geplant)

Rollback-Verfahren

Falls Release fehlerhaft ist:

# Tag löschen
git tag -d v1.1.0
git push origin :refs/tags/v1.1.0

# Release zurückziehen
# GitHub → Release → Delete

# Zu vorheriger Version zurück
git checkout v1.0.0

Release-Metriken

Nach jedem Release tracken:

  • Downloads
  • Fehlerberichte
  • Community-Feedback
  • Performance-Metriken
  • Adoption-Rate

Continuous Delivery

Langfristig geplant:

# Automated Tests auf jedem Commit
# Automated Releases bei Tags
# Automated Distribution

FAQ

F: Wie oft sollte ich Releases machen? A: Abhängig von Features/Bugfixes. Typisch: 1-2 pro Monat für stabile Versionen.

F: Was ist ein Hotfix? A: Ein kritischer Bugfix, der sofort nach Release notwendig ist.

F: Wie lange unterstütze ich alte Versionen? A: LTS: 12 Monate | Regular: 3 Monate

Letzte Aktualisierung: 2026-01-24
Version: 1.0.0