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.

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 (öffnet in einem neuen Tab). 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 für Updater-Signierung und Rollback-Verhalten. Installationsanleitungen für Benutzer stehen unter Herunterladen und Installieren.