osFoundry / Platform
Releases
Erstellen Sie ein Release mit Notes, Artefakten und Changelog – auf Wunsch von Maestro automatisch generiert.
Was es ist
Releases ist osFoundrys Weg, einen Punkt in deiner Git-Historie in etwas Ausgeliefertes und Versioniertes zu verwandeln: einen Tag, eine Reihe von Build-Artefakten, lesbare Release Notes und ein Changelog. Es lebt in der Code-&-Build-Oberfläche direkt neben deinen Repositorys, sodass ein Release nicht bedeutet, den Workspace zu verlassen, einen separaten CI-Anbieter anzubinden oder Commit-Nachrichten von Hand in ein Wiki zu kopieren. Du wählst den Commit oder Tag, benennst die Version, hängst die gebauten Dateien an und veröffentlichst.
Innerhalb von osFoundry können Changelog und Notes automatisch von Maestro erzeugt werden, dem Agenten des Workspace. Maestro liest den Commit-Bereich seit deinem letzten Release und entwirft ein Changelog sowie eine Zusammenfassung der Änderungen — gruppiert und für Menschen formuliert, nicht als rohe Liste von Commit-Betreffs. Da osFoundry nach dem Prinzip Bring-your-own-key arbeitet, läuft dieses Entwerfen gegen das Modell, das du angebunden hast (lokal, Cloud oder selbst gehostet); auf die Tokens kommt kein Wiederverkaufsaufschlag, und wenn du es auf ein lokales Modell richtest, bleiben Diff und Commit-Historie auf deinem Gerät. Der Entwurf ist ein Ausgangspunkt zum Bearbeiten, keine Blackbox: Über jede Zeile behältst du vor der Veröffentlichung das letzte Wort.
Das ist wichtig, weil Release Notes der Schritt sind, den Teams auslassen, sobald er Reibung bedeutet. Tag, Artefakte, Changelog und die Erzählung an einem Ort zu halten — direkt neben dem Code, den sie beschreiben — führt dazu, dass die Aufzeichnung dessen, was du ausgeliefert hast, tatsächlich geschrieben wird, korrekt bleibt und noch da ist, wenn jemand drei Monate später fragt: "Was hat sich in dieser Version geändert?"
Wichtige Funktionen
- Tagge einen Commit als benannte Version und veröffentliche ihn direkt aus der Code-&-Build-Oberfläche als Release, ohne externes CI
- Hänge Build-Artefakte — Binaries, Pakete, Archive — an das Release, damit die ausgelieferten Dateien bei der Version bleiben, die sie erzeugt hat
- Erzeuge automatisch ein Changelog aus dem Commit-Bereich seit deinem letzten Release, von Maestro entworfen und vor der Veröffentlichung voll bearbeitbar
- Schreibe Release Notes als lesbare Zusammenfassung der Änderungen, direkt neben dem Code statt in einem separaten Dokument
- BYOK und local-first: das Entwerfen des Changelogs läuft mit deinen eigenen Modell-Keys, und mit einem lokalen Modell verlässt deine Commit-Historie nie das Gerät
Anwendungsfälle
- Solo-Maintainer: Ein v1.2-Release erstellen, Maestro das Changelog aus 40 Commits entwerfen lassen, zwei Zeilen anpassen und mit angehängter gebauter Binary veröffentlichen
- Lead eines kleinen Teams: Einen versionierten Build mit Notes ausliefern, die deine Kolleg:innen wirklich lesen können — ohne pro Platz für ein separates Release-Tool zu zahlen
- Datenschutzbewusste:r Entwickler:in: Release Notes mit einem lokalen Modell erzeugen, damit proprietäre Commit-Nachrichten und Diffs auf der eigenen Maschine bleiben
Häufig gestellte Fragen
Schreibt osFoundry meine Release Notes für mich?
Es kann. Maestro liest die Commits seit deinem letzten Release und entwirft ein Changelog sowie eine Zusammenfassung in klarer Sprache, die du vor der Veröffentlichung bearbeitest. Es ist optional — du kannst alles von Hand schreiben — und die KI-Ausgabe ist immer ein Entwurf, den du prüfst, nie automatisch veröffentlicht.
Welches KI-Modell erzeugt das Changelog?
Das, das du angebunden hast. osFoundry ist Bring-your-own-key, das Entwerfen des Changelogs nutzt also dein eigenes Modell — lokal, Cloud oder selbst gehostet — ohne Aufschlag auf die Tokens. Richte es auf ein lokales Modell, und deine Commit-Historie bleibt auf deinem Gerät.
Kann ich Build-Artefakte an ein Release anhängen?
Ja. Ein Release verbindet den Versions-Tag, die Release Notes, das Changelog und die von dir gebauten Artefakte — Binaries, Pakete oder Archive — sodass die ausgelieferten Dateien bei genau der Version bleiben, die sie erzeugt hat.