OxideTerm Release
Veröffentlichen Sie eine OxideTerm-Version über die im Repository hinterlegte Automatisierung. Behandeln Sie den abgeschlossenen GUI-Lauf des Benutzers als Freigabe-Schranke und führen Sie standardmäßig keine Cargo-Tests aus.
Erforderliche Eingaben für die Veröffentlichung
Lösen Sie diese Werte auf, bevor Sie Änderungen für die Veröffentlichung vornehmen:
- Zielversion.
- Zielkanal:
stable,betaodergpui-preview. - Explizite Bestätigung, dass der Benutzer die GUI-Anwendung ausgeführt und die Veröffentlichung genehmigt hat.
- Detailgrad der Release-Notizen, wenn der Benutzer ausdrücklich
minimal,mediumoderdetailedwünscht; ansonstendetailed.
Leiten Sie den Kanal nur ab, wenn die Version eindeutig ist. Fragen Sie vor der Veröffentlichung nach, wenn keine GUI-Genehmigung vorliegt. Die Erstellung eines Changelogs oder ein Trockenlauf erfordert keine Genehmigung.
Kanalvertrag
| Kanal | Version | Tag | Changelog | Basisnotizen |
|---|---|---|---|---|
| Stable | X.Y.Z | vX.Y.Z | .github/release-notes/stable-changelog.md | .github/release-notes/stable.md |
| Beta | X.Y.Z-beta.N | vX.Y.Z-beta.N | .github/release-notes/beta-changelog.md | .github/release-notes/beta.md |
| GPUI-Vorschau | X.Y.Z-gpui-preview.N | gpui-vX.Y.Z-gpui-preview.N | .github/release-notes/gpui-preview-changelog.md | .github/release-notes/gpui-preview.md |
Erfinden Sie kein anderes Tag-Präfix. Der native Paket-Workflow erhält den vorhandenen Tag über seinen release_tag-Dispatch-Input und wählt die Release-Notizen aus diesem Tag aus.
Workflow
1. Repository-Zustand prüfen
Arbeiten Sie vom Stammverzeichnis des OxideTerm-Repositorys aus. Lesen Sie AGENTS.md, dann prüfen Sie:
git status --short --branch
git remote -v
git log -10 --oneline --decorate
Holen Sie sich den Publishing-Remote und die Tags, bevor Sie entscheiden, dass ein Tag verfügbar ist:
git fetch origin --tags
Bestätigen Sie, dass der Branch nicht hinter seinem Upstream zurückliegt oder von ihm abgewichen ist, und prüfen Sie den Ziel-Tag lokal und remote:
git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}
Bewahren Sie nicht zusammenhängende Benutzeränderungen auf. Stoppen Sie, wenn der beabsichtigte Release-Umfang nicht sicher getrennt werden kann oder der Branch abgewichen ist. Stoppen Sie bei einer normalen Veröffentlichung, wenn der Ziel-Tag existiert. Verschieben Sie einen vorhandenen Tag nur über das explizite Wiederherstellungsverfahren für abgebrochene Veröffentlichungen (siehe unten).
2. Changelog-Bereich festlegen
Führen Sie das gebündelte Hilfsskript aus, bevor Sie das Changelog schreiben:
python3 .agents/skills/oxideterm-release/scripts/release_context.py \
--repo . --channel <channel> --version <version>
Bevorzugen Sie den vorherigen erreichbaren Tag desselben Kanals als Basis:
- Stable vergleicht mit dem vorherigen Stable-Tag.
- Beta vergleicht mit dem vorherigen Beta-Tag.
- GPUI-Vorschau vergleicht mit dem vorherigen GPUI-Vorschau-Tag.
Für die erste Veröffentlichung in einem Kanal verwenden Sie den neuesten erreichbaren Release-Tag aus einem der drei Kanäle als Bootstrap-Basis. Verwenden Sie den Root-Commit nur, wenn das Repository keinen früheren erreichbaren Release-Tag hat. Dadurch bleibt das erste Beta- oder Vorschau-Changelog auf die Arbeit seit der tatsächlichen vorhergehenden Veröffentlichung beschränkt, anstatt das gesamte Repository zusammenzufassen.
Das Hilfsskript gibt den genauen Bereich, die Commits und eine Diff-Zusammenfassung aus. Prüfen Sie auch die tatsächlichen Änderungen, einschließlich beabsichtigter nicht festgeschriebener Änderungen:
git diff <previous-tag>..HEAD
git diff
git diff --cached
Leiten Sie die Release-Notizen nicht nur aus den Commit-Betreffen ab. Lesen Sie die aussagekräftigen Implementierungs- und benutzerseitigen Unterschiede. Schließen Sie mechanische Versionssprünge, Changelog-Bearbeitungen, reine Formatierungsänderungen und interne Details aus, die keine Auswirkungen auf die Veröffentlichung haben.
Pull-Requests und Mitwirkende ermitteln
Ordnen Sie für jeden Release-Kanal die Änderungen im genauen Release-Bereich ihren ursprünglichen Pull-Requests zu, bevor Sie die Notizen entwerfen. Die Commit-Liste des Hilfsskripts schließt Merge-Commits aus; prüfen Sie auch die Merge-Historie und die GitHub-Zuordnung von Commits zu PRs, damit Merge-, Squash- und Rebase-Merges eine Zuordnung erhalten:
git log --format='%H %s' <previous-tag>..<target-ref>
gh api --paginate repos/<owner>/<repo>/commits/<commit-sha>/pulls \
--jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <number> --repo <owner>/<repo> \
--json number,title,url,author,mergedAt,mergeCommit,commits
Behalten Sie eine Arbeitszuordnung der Nummer, URL, des Autoren-Logins und des tatsächlichen Beitrags jedes enthaltenen PRs bei. Entfernen Sie Duplikate von PRs, die für mehrere Commits zurückgegeben werden. Bestätigen Sie die Aufnahme anhand der Ziel-Historie und des Diffs; Merge-Daten allein legen den Release-Umfang nicht fest. Überprüfen Sie die ursprüngliche PR-Herkunft für gecherry-pickte Änderungen. Vollständig zurückgesetzte Änderungen dürfen nicht als ausgelieferte Funktionen dargestellt werden.
Verwenden Sie den PR-Autor, nicht die Person oder den Bot, der den Merge durchgeführt hat. Für Danksagungen schließen Sie bestätigte Projektbetreuer und Bot-Konten aus; gehen Sie nicht davon aus, dass ein menschlicher Mitwirkender ein Betreuer ist, nur weil GitHub ihn als COLLABORATOR oder MEMBER kennzeichnet. Behalten Sie die Anerkennung für externe PR-Arbeit bei, wenn der Betreuer Folgekorrekturen vorgenommen hat. Eine referenzierte Issue-Nummer ist kein Beleg für einen PR oder dessen Autor. Wenn die GitHub-Suche fehlschlägt, behalten Sie die ungeklärte Zuordnung in den Arbeitsnotizen und klären Sie sie vor der Fertigstellung der Release-Notizen; interpretieren Sie einen Suchfehler nicht als fehlende Beiträge.
3. Das Kanal-Changelog schreiben
Fügen Sie ## <version> als neuesten Eintrag im ausgewählten Changelog ein. Die Überschrift muss exakt der Version entsprechen, da .github/scripts/compose_release_notes.py sie verwendet, um den Eintrag zu lokalisieren. Die Überschrift ist eine Extraktionsgrenze, nicht unbedingt Teil des veröffentlichten Release-Textes.
Schreiben Sie jeden Versionseintrag als zwei vollständige Sprachblöcke in dieser Reihenfolge (zuerst Chinesisch, dann Englisch). Der Komponist fügt ganz oben für jeden Kanal Sprach-Sprunglinks in die zweisprachigen Release-Notizen ein:
## <version>
### 中文
<Chinesische Zusammenfassung und Abschnitte>
### English
<Englische Zusammenfassung und Abschnitte>
Halten Sie beide Blöcke strukturell ausgerichtet: Sie müssen die gleichen Ergebnisse, Einschränkungen, Validierungsstatus und Upgrade-Anforderungen in der gleichen Reihenfolge beschreiben. Übersetzen Sie in natürlicher Release-Notiz-Sprache und nicht Wort für Wort, und lassen Sie Produktnamen, Befehle, Dateinamen und Protokollnamen unverändert, wenn eine Übersetzung die Präzision verringern würde. Mischen Sie nicht Englisch und Chinesisch im selben Aufzählungspunkt. Verwenden Sie präzise, benutzerorientierte Vergangenheitsform im Englischen und präzise, abgeschlossene Handlungsformulierung im Chinesischen. Halten Sie den einleitenden Zusammenfassungsabsatz jeder Sprache in einer physikalischen Zeile, damit der GitHub-Release-Editor keinen künstlichen Umbruch anzeigt. Fassen Sie verwandte Commits zu einem Ergebnis zusammen und vermeiden Sie rohe Commit-Titel-Dumps, Implementierungsdetails, nicht belegte Leistungsbehauptungen und Behauptungen, die nicht verifiziert wurden. Verwenden Sie ein zurückhaltendes, semantisch relevantes Emoji pro Hauptabschnitt einer Stable-Release-Abschnittsüberschrift in beiden Blöcken; verzieren Sie nicht jeden Aufzählungspunkt oder mischen Sie mehrere Emoji-Stile in einem Abschnitt.
Für eine Fork-Veröffentlichung muss jeder Sprachblock Änderungen, die vom offiziellen OxideTerm-Upstream übernommen wurden, klar von Änderungen trennen, die vom Fork implementiert wurden. Verwenden Sie explizite lokalisierte Überschriften, die Upstream changes / 上游更新 und Fork-specific changes / Fork 自有更新 entsprechen; Unterabschnitte können unter ihnen verschachtelt werden, wenn der gewählte Detailgrad dies rechtfertigt. Klassifizieren Sie zusammengeführte oder gecherry-pickte offizielle Arbeiten unabhängig vom Commit-Autor als Upstream und klassifizieren Sie Verhalten, das nur für den veröffentlichenden Fork spezifisch ist, als Fork-spezifisch. Wenn ein Fork eine Upstream-Funktion ändert, beschreiben Sie die übernommene Fähigkeit unter Upstream und das materielle Delta des Forks unter Fork-spezifischen Änderungen. Wenn eine Kategorie im Release-Bereich keine Änderungen aufweist, geben Sie dies explizit an, anstatt die Kategorie wegzulassen. Lassen Sie niemals eine kombinierte Zusammenfassung oder einen Aufzählungspunkt implizieren, dass der Fork Upstream-Arbeit verfasst hat.
PR-Referenzen und Danksagungen
Folgen Sie dem Zuordnungsmuster in NyaTerm v1.2.12: PR-Referenzen neben den von ihnen eingeführten Änderungen, plus einen eigenen Abschnitt für Mitwirkende. Leiten Sie die tatsächlichen Einträge aus dem OxideTerm-Release-Bereich ab.
- Hängen Sie die verlinkten PR-Nummern an jeden Release-Notiz-Eintrag an, der über einen PR eingeführt wurde, einschließlich von Betreuern verfasster PRs. Verwenden Sie
（PR [#<number>](<pr-url>)）im Chinesischen und(PR [#<number>](<pr-url>))im Englischen. Setzen Sie die Referenz am Ende des relevanten Aufzählungspunkts oder Funktionsabsatzes, und nicht nur in der Mitwirkendenliste oder im vollständigen Changelog-Link. Halten Sie Issue-Links von PR-Links getrennt. Direkte Commits haben keine erfundene PR-Nummer. - Wenn mehrere PRs zu einem gruppierten Eintrag beigetragen haben, fügen Sie alle relevanten PR-Nummern einmal in diesem Eintrag ein. Ordnen Sie nur das Ergebnis zu, das durch jeden PR gestützt wird; trennen Sie eine unabhängige Folgeänderung eines Betreuers, wenn die Gruppierung dem falschen Autor zugeschrieben würde. Für PRs aus einem anderen Repository qualifizieren Sie das Link-Label mit
owner/repo#number. - Wenn die Veröffentlichung externe PR-Beiträge enthält, fügen Sie
#### 👥 贡献者innerhalb des chinesischen Blocks und#### 👥 Contributorsinnerhalb des englischen Blocks hinzu, nach den Änderungsabschnitten und vor Upgrade-Hinweisen, falls vorhanden. Danken Sie jedem externen PR-Autor, dessen Beitrag in dieser Version enthalten ist, einschließlich wiederkehrender Mitwirkender und Autoren von Dokumentations-, Übersetzungs-, Build- oder Paketierungsbeiträgen, deren Arbeit möglicherweise keinen eigenständigen Funktionsaufzählungspunkt rechtfertigt. - Listen Sie jeden Autor einmal pro Sprachblock auf, mit seinem verifizierten GitHub
@login, einer kurzen Beschreibung seines Beitrags und den verlinkten PR-Nummern. Stimmen Sie Autoren und PR-Referenzen in beiden Sprachen ab. Ein allgemeiner Dank oder der automatische Avatar-Streifen von GitHub ersetzt diese Einträge nicht. Wenn Sie Erstautoren identifizieren, überprüfen Sie frühere Repository-Beiträge; eine ListeNew Contributorsergänzt den vollständigen Danksagungsabschnitt. - Wenden Sie die Zuordnung auf jeder Detailstufe und in jedem Kanal an. Wenn der verifizierte Bereich keinen externen PR-Beitrag enthält, lassen Sie den Mitwirkendenabschnitt weg, anstatt eine leere Überschrift hinzuzufügen. Ein PR außerhalb des Release-Bereichs wird nicht als neuer Beitrag zu dieser Version anerkannt.
Beispiel für Mitwirkendeneinträge (ersetzen Sie die Platzhalter durch verifizierte Release-Daten):
#### 👥 贡献者
感谢以下外部贡献者参与本次更新：
- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。
#### 👥 Contributors
Thank you to the external contributors to this release:
- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).
Platzieren Sie die beiden Beispielabschnitte in ihren jeweiligen Sprachblöcken, nicht zusammen als dritten zweisprachigen Abschnitt.
Detailgrad der Release-Notizen
Verwenden Sie für den englischen und den chinesischen Block die gleiche Stufe. Die Stufen steuern die Abdeckung und Gruppierung, nicht eine obligatorische Wortanzahl. Lassen Sie niemals eine bahnbrechende Änderung, eine Sicherheitsgrenze, eine Upgrade-Anforderung, eine bekannte Einschränkung oder ein materielles Kompatibilitätsproblem weg, nur um eine kürzere Stufe zu erfüllen.
| Stufe | Erforderliche Dichte |
|---|---|
minimal | Nur verwenden, wenn der Benutzer es ausdrücklich anfordert. Schreiben Sie eine kurze Zusammenfassung, gefolgt von etwa 2–5 hochgradig konsolidierten Ergebnis-Aufzählungspunkten, mit höchstens ein oder zwei Überschriften, wenn sie das Scannen wesentlich verbessern. Decken Sie nur die definierenden benutzersichtbaren Änderungen und erforderlichen Warnungen der Veröffentlichung ab. |
medium | Nur verwenden, wenn der Benutzer es ausdrücklich anfordert. Schreiben Sie eine Zusammenfassung, eine kleine Anzahl nützlicher Abschnitte und gruppierte Aufzählungspunkte, die die wichtigsten Funktionen, Korrekturen sowie Sicherheits- oder Kompatibilitätsergebnisse abdecken. Konsolidieren Sie verwandte unterstützende Workflows, anstatt jeden einzeln aufzulisten. |
detailed | Standard, es sei denn, der Benutzer wählt ausdrücklich eine andere Stufe. Ordnen Sie die Notizen nach sinnvollen Subsystemen oder Workflows und geben Sie jeder einzelnen benutzersichtbaren Fähigkeit, Verhaltensänderung, Kompatibilitätskorrektur, unterstützten Einschränkung und verifizierten Leistungs- oder Validierungsergebnissen genügend Raum, um verstanden zu werden, ohne das Diff lesen zu müssen. Fügen Sie unterstützende Workflows hinzu, wenn sie wesentlich beeinflussen, wie Benutzer die Änderung verstehen oder verwenden, aber fügen Sie keine Fülltexte hinzu, wenn eine Veröffentlichung weniger tatsächliche Änderungen hat. |
Behandeln Sie die Stufen als Richtlinien für Abdeckung und Gruppierung, nicht als feste Vorlagen. Bestimmen Sie zuerst das vollständige faktische Delta, konsolidieren Sie es dann auf die ausgewählte Stufe. Wenn der Benutzer nur „Schreibe die Release-Notizen“ oder „Bereite die Veröffentlichung vor“ sagt, verwenden Sie detailed.
Wenden Sie kanalspezifische Schwerpunkte an:
- Stable: Fassen Sie das vollständige Delta seit dem vorherigen Stable-Tag zusammen. Beginnen Sie in jedem Sprachblock mit einer kurzen Release-Zusammenfassung, verwenden Sie dann nur nützliche Abschnitte wie
#### ✨ Highlights/#### ✨ 重点更新,#### 🛠️ Fixes/#### 🛠️ 修复,#### 🔒 Security/#### 🔒 安全oder#### 🧰 Release Maintenance/#### 🧰 发布维护. Betonen Sie benutzersichtbares Verhalten und Kompatibilität. Der zusammengesetzte GitHub-Release-Text muss mit der Navigation[中文](#中文) | [English](#english)beginnen, gefolgt vom vollständigen Block### 中文und dann dem passenden Block### English. Lassen Sie sowohl eine produkthauptüberschrift wie# OxideTerm 2.0als auch eine wiederholte Versionsüberschrift wie## 2.0.7weg, setzen Sie dann## 📥 Download for your system, Installationstipps und Links nach beiden Sprachblöcken. - Beta: Fassen Sie das Delta seit dem vorherigen Beta-Tag in vollständigen englischen und chinesischen Blöcken zusammen. Geben Sie an, was sich dem Stable nähert, was sich geändert hat und welche Workflows validiert werden müssen. Erwähnen Sie bekannte Einschränkungen nur, wenn sie durch den Diff oder den Issue-Kontext gestützt werden, und fügen Sie sie in beide Sprachen ein.
- GPUI-Vorschau: Fassen Sie das Delta seit dem vorherigen GPUI-Vorschau-Tag in vollständigen englischen und chinesischen Blöcken zusammen. Konzentrieren Sie sich auf neu testbare native UI/Laufzeitarbeit, Parität, grobe Kanten und konkrete Testziele. Wenden Sie die ausgewählte Detailstufe an, während Sie das Schreiben testorientiert halten, anstatt Vorschau-Notizen in Stable-Release-Marketing zu verwandeln.
Wenn es keinen früheren Tag für diesen Kanal gibt, geben Sie an, welcher vorhergehende Release-Tag als Bootstrap-Basis verwendet wurde.
4. Das Repository-Versionsskript ausführen
Verwenden Sie immer das Repository-Skript; bearbeiten Sie niemals manuell die Workspace-Version oder die Lockdatei:
python3 scripts/release/bump_version.py <version>
Dies validiert SemVer, aktualisiert [workspace.package] und aktualisiert Cargo.lock offline. README-Abzeichen zeigen automatisch die neueste GitHub-Veröffentlichung an und benötigen keine Versionsbearbeitungen.
5. Leichte Release-Validierung durchführen
Führen Sie cargo test nicht aus...
[Fortsetzung folgt…]