Version OxideTerm

Publier une version d'OxideTerm via l'automatisation du dépôt. Considérez l'exécution GUI terminée par l'utilisateur comme la porte de sortie de la version et n'exécutez pas les tests Cargo par défaut.

Entrée requise pour la version

Résolvez ces valeurs avant d'apporter des modifications de version :

Version cible.
Canal cible : stable, beta ou gpui-preview.
Confirmation explicite que l'utilisateur a exécuté l'application GUI et approuvé la publication.
Niveau de détail des notes de version lorsque l'utilisateur demande explicitement minimal, medium ou detailed ; sinon, utilisez detailed.

Déduisez le canal uniquement lorsque la version est sans ambiguïté. Demandez avant de publier si l'approbation GUI est absente. La préparation d'un journal des modifications ou d'un essai à blanc ne nécessite pas d'approbation.

Contrat de canal

Canal	Version	Tag	Journal des modifications	Notes de base
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`
Préversion GPUI	`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`

N'inventez pas un autre préfixe de tag. Le workflow de package natif reçoit le tag existant via son entrée de distribution release_tag et sélectionne les notes de version à partir de ce tag.

Flux de travail

1. Inspecter l'état du dépôt

Travaillez depuis la racine du dépôt OxideTerm. Lisez AGENTS.md, puis inspectez :

git status --short --branch
git remote -v
git log -10 --oneline --decorate

Récupérez le dépôt de publication et les tags avant de décider qu'un tag est disponible :

git fetch origin --tags

Confirmez que la branche n'est pas en retard ou divergée de sa branche amont, et inspectez le tag cible localement et à distance :

git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}

Préservez les modifications utilisateur non liées. Arrêtez-vous si le périmètre de version prévue ne peut pas être séparé en toute sécurité ou si la branche a divergé. Pour une version ordinaire, arrêtez-vous lorsque le tag cible existe. Ne déplacez un tag existant que via la procédure explicite de récupération de version annulée ci-dessous.

2. Établir la plage du journal des modifications

Exécutez l'outil intégré avant d'écrire le journal des modifications :

python3 .agents/skills/oxideterm-release/scripts/release_context.py \
  --repo . --channel <channel> --version <version>

Préférez le tag précédent accessible du même canal comme référence :

Stable compare avec le tag stable précédent.
Beta compare avec le tag beta précédent.
Préversion GPUI compare avec le tag de préversion GPUI précédent.

Pour la première version d'un canal, utilisez le tag de version accessible le plus récent parmi les trois canaux comme référence de démarrage. Utilisez le commit racine uniquement lorsque le dépôt n'a pas de tag de version accessible antérieur. Cela permet de limiter le premier journal des modifications bêta ou préversion au travail effectué depuis la version précédente réelle au lieu de résumer l'intégralité du dépôt.

L'outil affiche la plage exacte, les commits et le résumé des différences. Inspectez également les modifications réelles, y compris les modifications non commitées prévues :

git diff <previous-tag>..HEAD
git diff
git diff --cached

Ne dérivez pas les notes de version uniquement des sujets de commit. Lisez les différences d'implémentation significatives et les différences visibles par l'utilisateur. Excluez les changements mécaniques de version, les modifications du journal des modifications, le remaniement de formatage uniquement et les détails internes sans impact sur la version.

Résoudre les demandes de tirage et les contributeurs

Pour chaque canal de version, mappez les changements dans la plage de version exacte à leurs demandes de tirage d'origine avant de rédiger les notes. La liste des commits de l'outil exclut les commits de fusion ; inspectez également l'historique des fusions et les associations commit-à-PR de GitHub pour que les fusions par merge, squash et rebase reçoivent une attribution :

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

Conservez un mappage fonctionnel de chaque PR inclus avec son numéro, son URL, le login de l'auteur et sa contribution réelle. Dédupliquez les PR retournées pour plusieurs commits. Confirmez l'inclusion par rapport à l'historique cible et aux différences ; les dates de fusion seules n'établissent pas le périmètre de la version. Vérifiez la provenance originale des PR pour les changements cherry-pickés. Les changements complètement annulés ne doivent pas être présentés comme des fonctionnalités livrées.

Utilisez l'auteur de la PR, pas la personne ou le bot qui l'a fusionnée. Pour les remerciements aux contributeurs, excluez les mainteneurs confirmés du projet et les comptes de bot ; ne présumez pas qu'un contributeur humain est un mainteneur simplement parce que GitHub l'étiquette COLLABORATOR ou MEMBER. Conservez le crédit pour le travail de PR externe lorsque le mainteneur a effectué des correctifs de suivi. Un numéro de problème référencé n'est pas une preuve d'une PR ou de son auteur. Si la recherche GitHub échoue, conservez l'attribution non résolue dans les notes de travail et résolvez-la avant de finaliser les notes de version ; n'interprétez pas l'échec de la recherche comme une absence de contributions.

3. Écrire le journal des modifications du canal

Insérez ## <version> comme l'entrée la plus récente dans le journal des modifications sélectionné. L'en-tête doit correspondre exactement à la version car .github/scripts/compose_release_notes.py l'utilise pour localiser l'entrée. L'en-tête est une limite d'extraction, pas nécessairement une partie du corps de la version publiée.

Écrivez chaque entrée de version sous la forme de deux blocs de langue complets dans cet ordre (chinois d'abord, anglais ensuite). Le compositeur ajoute des liens de saut de langue tout en haut des notes de version bilingues pour chaque canal :

## <version>

### 中文

<Résumé et sections en chinois>

### English

<Résumé et sections en anglais>

Assurez-vous que les deux blocs sont structurellement alignés : ils doivent décrire les mêmes résultats, limitations, statut de validation et exigences de mise à niveau dans le même ordre. Traduisez pour un langage naturel de notes de version plutôt que mot à mot, et conservez les noms de produits, commandes, noms de fichiers et noms de protocoles inchangés lorsque la traduction réduirait la précision. Ne mélangez pas l'anglais et le chinois dans la même puce. Utilisez un passé concis orienté utilisateur en anglais et une formulation d'action achevée concise en chinois. Gardez le paragraphe de résumé d'ouverture de chaque langue sur une seule ligne physique afin que l'éditeur de version GitHub n'affiche pas de saut artificiel. Combinez les commits liés en un seul résultat et évitez les vidages bruts de titres de commit, les détails d'implémentation, les affirmations de performance non étayées et les affirmations qui n'ont pas été vérifiées. Utilisez un seul emoji pertinent et retenu sur chaque en-tête de section principale de version stable dans les deux blocs ; ne décorez pas chaque puce et ne mélangez pas plusieurs styles d'emoji dans une même section.

Pour une version de fork, chaque bloc de langue doit séparer clairement les changements hérités d'OxideTerm officiel en amont des changements implémentés par le fork. Utilisez des en-têtes localisés explicites équivalents à Upstream changes / 上游更新 et Fork-specific changes / Fork 自有更新 ; les en-têtes de sous-système peuvent être imbriqués en dessous lorsque le niveau de détail sélectionné le justifie. Classez le travail officiel fusionné ou cherry-pické comme amont, quel que soit l'auteur du commit, et classez le comportement propre au fork de publication comme spécifique au fork. Lorsqu'un fork modifie une fonctionnalité en amont, décrivez la capacité héritée sous amont et le delta matériel du fork sous les changements spécifiques au fork. Si l'une ou l'autre catégorie n'a pas de changement dans la plage de version, indiquez-le explicitement au lieu d'omettre la catégorie. Ne laissez jamais un résumé combiné ou une puce suggérer que le fork a écrit le travail en amont.

Références PR et remerciements aux contributeurs

Suivez le modèle d'attribution dans NyaTerm v1.2.12 : références PR à côté des changements qu'elles ont introduits, plus une section dédiée aux contributeurs. Dérivez les entrées réelles de la plage de version d'OxideTerm.

Ajoutez des numéros de PR liés à chaque élément de notes de version introduit via une PR, y compris les PR des mainteneurs. Utilisez （PR [#<number>](<pr-url>)） en chinois et (PR [#<number>](<pr-url>)) en anglais. Placez la référence à la fin de la puce ou du paragraphe de fonctionnalité pertinent, plutôt que uniquement dans la liste des contributeurs ou le lien vers le journal complet. Gardez les liens de problème distincts des liens de PR. Les commits directs n'ont pas de numéro de PR inventé.
Lorsque plusieurs PR ont contribué à un élément groupé, incluez tous les numéros de PR pertinents une fois dans cet élément. Attribuez uniquement le résultat soutenu par chaque PR ; séparez un changement de suivi indépendant d'un mainteneur lorsque le regroupement créditerait le mauvais auteur. Pour les PR d'un autre dépôt, qualifiez le libellé du lien avec owner/repo#number.
Chaque fois que la version inclut des contributions de PR externes, ajoutez #### 👥 贡献者 dans le bloc chinois et #### 👥 Contributors dans le bloc anglais, après les sections de modification et avant les notes de mise à niveau le cas échéant. Remerciez chaque auteur de PR externe dont la contribution est incluse dans cette version, y compris les contributeurs récurrents et les contributeurs à la documentation, à la traduction, à la construction ou à l'empaquetage dont le travail peut ne pas justifier une puce de fonctionnalité autonome.
Listez chaque auteur une fois par bloc de langue en utilisant son @login GitHub vérifié, une brève description de sa contribution et les numéros de PR liés. Faites correspondre les auteurs et les références PR dans les deux langues. Un remerciement générique ou la bande d'avatar automatique de GitHub ne remplace pas ces entrées. Si vous identifiez des contributeurs pour la première fois, vérifiez les contributions antérieures au dépôt ; une liste Nouveaux contributeurs complète la section de remerciements complète.
Appliquez l'attribution à chaque niveau de détail et dans chaque canal. Si la plage vérifiée ne contient aucune contribution de PR externe, omettez la section des contributeurs plutôt que d'ajouter un en-tête vide. Une PR en dehors de la plage de version n'est pas créditée comme une nouvelle contribution à cette version.

Exemple d'entrées de contributeurs (remplacez les espaces réservés par des données de version vérifiées) :

#### 👥 贡献者

感谢以下外部贡献者参与本次更新：

- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。

#### 👥 Contributors

Thank you to the external contributors to this release:

- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).

Placez les deux sections d'exemple dans leurs blocs de langue respectifs, pas ensemble comme une troisième section bilingue.

Niveau de détail des notes de version

Utilisez le même niveau pour les blocs anglais et chinois. Les niveaux contrôlent la couverture et le regroupement, pas un nombre de mots obligatoire. N'omettez jamais un changement cassant, une limite de sécurité, une exigence de mise à niveau, une limitation connue ou un problème de compatibilité matériel simplement pour satisfaire un niveau plus court.

Niveau	Densité requise
`minimal`	Utilisez uniquement lorsque l'utilisateur le demande explicitement. Écrivez un court résumé suivi d'environ 2 à 5 puces de résultats hautement consolidées, avec au plus un ou deux en-têtes lorsqu'ils améliorent matériellement la lecture. Couvrez uniquement les changements visibles par l'utilisateur déterminants de la version et les avertissements requis.
`medium`	Utilisez uniquement lorsque l'utilisateur le demande explicitement. Écrivez un résumé, un petit nombre de sections utiles et des puces groupées couvrant les principales fonctionnalités, correctifs et résultats de sécurité ou de compatibilité. Consolidez les workflows de support liés au lieu de les énumérer séparément.
`detailed`	Par défaut sauf si l'utilisateur choisit explicitement un autre niveau. Organisez les notes par sous-système ou workflow significatif et donnez à chaque capacité visible par l'utilisateur distincte, changement de comportement, correctif de compatibilité, limitation prise en charge et résultat de performance ou de validation vérifié suffisamment d'espace pour être compris sans lire le diff. Incluez les workflows de support lorsqu'ils affectent matériellement la façon dont les utilisateurs comprennent ou utilisent le changement, mais n'ajoutez pas de remplissage lorsqu'une version a moins de changements réels.

Considérez les niveaux comme des directives de couverture et de regroupement, pas des modèles fixes. Déterminez d'abord le delta factuel complet, puis consolidez-le au niveau sélectionné. Si l'utilisateur dit simplement « écrire les notes de version » ou « préparer la version », utilisez detailed.

Appliquez une emphase spécifique au canal :

Stable : Résumez le delta complet depuis le tag stable précédent. Dans chaque bloc de langue, commencez par un court résumé de version, puis utilisez uniquement des sections utiles telles que #### ✨ Highlights / #### ✨ 重点更新, #### 🛠️ Fixes / #### 🛠️ 修复, #### 🔒 Security / #### 🔒 安全, ou #### 🧰 Release Maintenance / #### 🧰 发布维护. Mettez l'accent sur le comportement visible par l'utilisateur et la compatibilité. Le corps de la version GitHub composé doit commencer par la navigation [中文](#中文) | [English](#english), suivie du bloc complet ### 中文 puis du bloc correspondant ### English, omettez à la fois un en-tête de produit majeur tel que # OxideTerm 2.0 et un en-tête de version répété tel que ## 2.0.7, puis placez ## 📥 Download for your system, les conseils d'installation et les liens après les deux blocs de langue.
Beta : Résumez le delta depuis le tag beta précédent dans des blocs anglais et chinois complets. Indiquez ce qui approche de la stabilité, ce qui a changé et quels workflows nécessitent une validation. Mentionnez les limitations connues uniquement lorsqu'elles sont étayées par le diff ou le contexte du problème, et incluez-les dans les deux langues.
Préversion GPUI : Résumez le delta depuis le tag de préversion GPUI précédent dans des blocs anglais et chinois complets. Concentrez-vous sur les nouveaux travaux d'interface utilisateur/exécution natifs testables, la parité, les angles morts et les cibles de test concrètes. Appliquez le niveau de détail sélectionné tout en gardant l'écriture orientée test plutôt que de transformer les notes de préversion en marketing de version stable.

S'il n'y a pas de tag antérieur pour ce canal, indiquez quel tag de version précédent a été utilisé comme référence de démarrage.

4. Exécuter le script de version du dépôt

Utilisez toujours le script du dépôt ; ne modifiez jamais manuellement la version de l'espace de travail ou le fichier de verrouillage :

python3 scripts/release/bump_version.py <version>

Cela valide SemVer, met à jour [workspace.package] et rafraîchit Cargo.lock hors ligne. Les badges README affichent automatiquement la dernière version GitHub et ne nécessitent aucune modification de version.

AnalyseDeCircuit/oxideterm

Qu'est-ce que oxideterm ?

Demander à votre IA préférée

Documentation