# Oleafly veröffentlichen

Aus einem Version-Tag einen vollständigen Draft bauen, jedes Plattform-Artefakt prüfen und dann über den abgesicherten Release-Workflow veröffentlichen.

Oleafly-Releases haben zwei bewusst getrennte Stufen. Ein Version-Tag baut und prüft einen Draft. Eine betreuende Person veröffentlicht denselben Draft mit einem separaten Workflow-Lauf.

Ein Push auf `main` startet die CI, erstellt aber kein Release.

## Den Draft bauen

Beginnen Sie mit einem aktuellen `main`-Branch und grüner CI.

```sh
git switch main
git pull --ff-only
./scripts/bump-version.sh 0.3.6
git commit -am "chore: release v0.3.6"
git push origin main
git tag v0.3.6
git push origin v0.3.6
```

Das Tag startet `.github/workflows/release.yml`. Es baut diese Ziele:

| Ziel | Installer |
|---|---|
| macOS Apple Silicon | `.dmg` |
| Windows x64 | `.msi` und `-setup.exe` |
| Linux x64 | `.AppImage` und `.deb` |
| Linux ARM64 | `.AppImage` und `.deb` |

Jedes Ziel lädt seine gepinnten Compiler-Sidecars herunter und prüft sie. Der Workflow führt danach alle vier Updater-Fragmente zu einer `latest.json` zusammen. Der Draft gilt erst als bereit, wenn jeder benötigte Installer und jeder Updater-Eintrag vorhanden ist.

## Den Draft prüfen

Öffnen Sie den Draft auf der [GitHub-Releases-Seite](https://github.com/Oleafly/Oleafly/releases). Prüfen Sie die Releasenotizen, die Installer-Namen, Prüfsummen, Signaturen und die `latest.json`. Veröffentlichen Sie keinen unvollständigen Draft.

## Veröffentlichen

Öffnen Sie **Actions → Release → Run workflow**. Geben Sie dasselbe Tag ein und wählen Sie **Publish the release**.

Der Veröffentlichungslauf wiederholt die Build- und Artefaktprüfungen. Er führt außerdem Live-Vertragstests gegen Anthropic und Google mit dem Release Candidate aus. Der letzte Job verweigert das Veröffentlichen, solange nicht jede unterstützte Plattform und der vollständige Updater-Feed vorhanden sind.

Das Veröffentlichen macht die `latest.json` für installierte Apps sichtbar. Betrachten Sie es als unumkehrbaren Produktionsvorgang. Schlägt der Veröffentlichungslauf fehl, lassen Sie das Release als Draft, beheben Sie die Ursache und starten Sie ihn erneut.

## Versionsnummern

Oleafly folgt der semantischen Versionierung:

- **Patch**, etwa von `0.3.5` auf `0.3.6`, für kompatible Fehlerbehebungen.
- **Minor**, etwa von `0.3.5` auf `0.4.0`, für kompatible Funktionen.
- **Major**, etwa von `0.3.5` auf `1.0.0`, für brechende Änderungen oder das erste stabile Release.

## Wichtige Prüfungen

- Das Tag muss zu `package.json`, `src-tauri/tauri.conf.json`, `src-tauri/Cargo.toml` und `src-tauri/Cargo.lock` passen. Verwenden Sie `scripts/bump-version.sh`, statt sie einzeln zu bearbeiten.
- Die Releasenotizen stammen aus dem passenden Versionsabschnitt in `CHANGELOG.md`.
- Verwenden Sie ein veröffentlichtes Tag nicht erneut. Beheben Sie bei einem fehlgeschlagenen Draft den Branch und erstellen Sie eine neue Version, es sei denn, es gibt einen klaren Grund, das unveröffentlichte Tag zu ersetzen.
- Signieren und Notarisieren unter macOS verwenden die Apple-Release-Secrets. Windows Authenticode verwendet Azure Artifact Signing, wenn dessen Secrets konfiguriert sind. Updater-Signaturen verwenden den separaten Tauri-Signierschlüssel.

Siehe [Automatische Updates](/docs/engineering/updates/) für Updater-Signierung und Rollback-Verhalten. Installationsanleitungen für Benutzer stehen unter [Herunterladen und Installieren](/docs/install/).