OxideTerm Release
Publique um release do OxideTerm através da automação de propriedade do repositório. Trate a execução GUI concluída pelo usuário como a porta de liberação e não execute testes Cargo por padrão.
Informações de entrada obrigatórias para o release
Resolva estes valores antes de fazer alterações de release:
- Versão alvo.
- Canal alvo:
stable,betaougpui-preview. - Confirmação explícita de que o usuário executou o aplicativo GUI e aprovou a publicação.
- Nível de detalhe das notas de release quando o usuário solicitar explicitamente
minimal,mediumoudetailed; caso contrário, usedetailed.
Infira o canal apenas quando a versão for inequívoca. Pergunte antes de publicar se a aprovação da GUI estiver ausente. Preparar um changelog ou execução a seco não requer aprovação.
Contrato do canal
| Canal | Versão | Tag | Changelog | Notas 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 |
| Preview 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ão invente outro prefixo de tag. O workflow de pacote nativo recebe a tag existente através de sua entrada de despacho release_tag e seleciona as notas de release a partir dessa tag.
Fluxo de trabalho
1. Inspecionar o estado do repositório
Trabalhe a partir da raiz do repositório OxideTerm. Leia AGENTS.md, depois inspecione:
git status --short --branch
git remote -v
git log -10 --oneline --decorate
Busque o remote de publicação e as tags antes de decidir que uma tag está disponível:
git fetch origin --tags
Confirme que o branch não está atrás ou divergente de seu upstream, e inspecione a tag alvo local e remotamente:
git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}
Preserve alterações não relacionadas do usuário. Pare se o escopo pretendido do release não puder ser separado com segurança ou se o branch tiver divergido. Para um release comum, pare quando a tag alvo existir. Mova uma tag existente apenas através do procedimento explícito de recuperação de release cancelado abaixo.
2. Estabelecer o intervalo do changelog
Execute o helper incluso antes de escrever o changelog:
python3 .agents/skills/oxideterm-release/scripts/release_context.py \
--repo . --channel <canal> --version <versão>
Prefira a tag anterior alcançável do mesmo canal como linha de base:
- Stable compara com a tag stable anterior.
- Beta compara com a tag beta anterior.
- Preview GPUI compara com a tag anterior de preview GPUI.
Para o primeiro release em um canal, use a tag de release alcançável mais recente de qualquer um dos três canais como linha de base de inicialização. Use o commit raiz apenas quando o repositório não tiver uma tag de release anterior alcançável. Isso mantém o changelog de um primeiro beta ou preview com escopo para o trabalho desde o release anterior real, em vez de resumir todo o repositório.
O helper imprime o intervalo exato, commits e resumo do diff. Também inspecione as mudanças reais, incluindo alterações não commitadas pretendidas:
git diff <tag-anterior>..HEAD
git diff
git diff --cached
Não derive as notas de release apenas dos assuntos dos commits. Leia as diferenças significativas de implementação e voltadas ao usuário. Exclua bumps de versão mecânicos, edições de changelog, alterações apenas de formatação e detalhes internos que não tenham impacto no release.
Resolver pull requests e contribuidores
Para cada canal de release, mapeie as mudanças no intervalo exato do release para seus pull requests de origem antes de redigir as notas. A lista de commits do helper exclui merge commits; inspecione o histórico de merge e as associações commit-a-PR do GitHub também, para que merges normais, squash e rebase recebam atribuição:
git log --format='%H %s' <tag-anterior>..<ref-alvo>
gh api --paginate repos/<proprietário>/<repositório>/commits/<sha-commit>/pulls \
--jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <número> --repo <proprietário>/<repositório> \
--json number,title,url,author,mergedAt,mergeCommit,commits
Mantenha um mapeamento funcional do número, URL, login do autor e contribuição real de cada PR incluído. Desduplique PRs retornados para múltiplos commits. Confirme a inclusão em relação ao histórico e diff alvo; apenas as datas de merge não estabelecem o escopo do release. Verifique a proveniência original do PR para mudanças cherry-picked. Mudanças totalmente revertidas não devem ser apresentadas como funcionalidades lançadas.
Use o autor do PR, não a pessoa ou bot que o mergeou. Para agradecimentos a contribuidores, exclua mantenedores confirmados do projeto e contas de bot; não presuma que um contribuidor humano é um mantenedor apenas porque o GitHub os rotula como COLLABORATOR ou MEMBER. Mantenha crédito para trabalho externo de PR quando o mantenedor fez correções de acompanhamento. Um número de issue referenciado não é evidência de um PR ou seu autor. Se a consulta ao GitHub falhar, mantenha a atribuição não resolvida nas notas de trabalho e resolva antes de finalizar as notas de release; não interprete a falha de consulta como ausência de contribuições.
3. Escrever o changelog do canal
Insira ## <versão> como a entrada mais recente no changelog selecionado. O cabeçalho deve corresponder exatamente à versão porque .github/scripts/compose_release_notes.py o usa para localizar a entrada. O cabeçalho é um limite de extração, não necessariamente parte do corpo do release publicado.
Escreva cada entrada de versão como dois blocos de idioma completos nesta ordem (chinês primeiro, inglês depois). O compositor adiciona links de salto de idioma no topo das notas de release bilíngues para cada canal:
## <versão>
### 中文
<Resumo e seções em chinês>
### English
<Resumo e seções em inglês>
Mantenha ambos os blocos estruturalmente alinhados: eles devem descrever os mesmos resultados, limitações, status de validação e requisitos de atualização na mesma ordem. Traduza para uma linguagem natural de notas de release em vez de palavra por palavra, e mantenha nomes de produtos, comandos, nomes de arquivos e nomes de protocolo inalterados quando a tradução reduzir a precisão. Não mescle inglês e chinês no mesmo item. Use passado conciso voltado ao usuário em inglês e redação de ação concluída concisa em chinês. Mantenha o parágrafo de resumo de abertura de cada idioma em uma linha física para que o editor do GitHub Release não mostre uma quebra artificial. Combine commits relacionados em um resultado e evite despejos de títulos de commit brutos, trivia de implementação, alegações de desempenho não suportadas e alegações que não foram verificadas. Use um emoji contido e semanticamente relevante em cada cabeçalho de seção principal de release estável em ambos os blocos; não decore cada item ou misture múltiplos estilos de emoji dentro de uma seção.
Para um release de fork, cada bloco de idioma deve separar claramente as mudanças herdadas do upstream oficial do OxideTerm das mudanças implementadas pelo fork. Use cabeçalhos localizados explícitos equivalentes a Upstream changes / 上游更新 e Fork-specific changes / Fork 自有更新; cabeçalhos de subsistema podem estar aninhados abaixo deles quando o nível de detalhe selecionado justificar. Classifique trabalho oficial mergeado ou cherry-picked como upstream independentemente do autor do commit, e classifique comportamento único do fork de publicação como específico do fork. Quando um fork modifica uma funcionalidade upstream, descreva a capacidade herdada sob upstream e o delta material do fork sob mudanças específicas do fork. Se qualquer categoria não tiver mudanças no intervalo do release, declare isso explicitamente em vez de omitir a categoria. Nunca deixe um resumo combinado ou item implicar que o fork escreveu trabalho upstream.
Referências de PR e agradecimentos a contribuidores
Siga o padrão de atribuição em NyaTerm v1.2.12: referências de PR ao lado das mudanças que introduziram, mais uma seção dedicada a contribuidores. Derive as entradas reais do intervalo de release do OxideTerm.
- Anexe números de PR vinculados a cada item de nota de release introduzido através de um PR, incluindo PRs de autoria de mantenedores. Use
（PR [#<número>](<url-pr>)）em chinês e(PR [#<número>](<url-pr>))em inglês. Coloque a referência no final do item ou parágrafo de funcionalidade relevante, em vez de apenas na lista de contribuidores ou link completo do changelog. Mantenha links de issue distintos de links de PR. Commits diretos não têm número de PR inventado. - Quando vários PRs contribuíram para um item agrupado, inclua todos os números de PR relevantes uma vez nesse item. Atribua apenas o resultado suportado por cada PR; separe uma mudança de acompanhamento independente de um mantenedor quando agrupar creditaria o autor errado. Para PRs de outro repositório, qualifique o rótulo do link com
proprietário/repositório#número. - Sempre que o release incluir contribuições externas de PR, adicione
#### 👥 贡献者dentro do bloco chinês e#### 👥 Contributorsdentro do bloco inglês, após as seções de mudança e antes das notas de atualização, quando presentes. Agradeça a cada autor externo de PR cuja contribuição está incluída neste release, incluindo contribuidores recorrentes e contribuidores de documentação, tradução, build ou empacotamento cujo trabalho pode não justificar um item de funcionalidade independente. - Liste cada autor uma vez por bloco de idioma usando seu
@loginverificado do GitHub, uma breve descrição de sua contribuição e números de PR vinculados. Corresponda autores e referências de PR em ambos os idiomas. Um agradecimento genérico ou a faixa automática de avatar do GitHub não substitui essas entradas. Se identificar contribuidores pela primeira vez, verifique contribuições anteriores ao repositório; uma listaNew Contributorscomplementa a seção de agradecimentos completa. - Aplique atribuição em todos os níveis de detalhe e em todos os canais. Se o intervalo verificado não contiver contribuição externa de PR, omita a seção de contribuidores em vez de adicionar um cabeçalho vazio. Um PR fora do intervalo do release não é creditado como uma nova contribuição para esta versão.
Exemplo de entradas de contribuidores (substitua os placeholders pelos dados verificados do release):
#### 👥 贡献者
感谢以下外部贡献者参与本次更新：
- @<login>：<contribuição específica>（PR [#<número>](<url-pr>)）。
#### 👥 Contributors
Thank you to the external contributors to this release:
- @<login>: <contribuição específica> (PR [#<número>](<url-pr>)).
Coloque as duas seções de exemplo em seus respectivos blocos de idioma, não juntas como uma terceira seção bilíngue.
Nível de detalhe das notas de release
Use o mesmo nível para os blocos inglês e chinês. Os níveis controlam a cobertura e o agrupamento, não uma contagem obrigatória de palavras. Nunca omita uma mudança de quebra, limite de segurança, requisito de atualização, limitação conhecida ou problema material de compatibilidade apenas para satisfazer um nível mais curto.
| Nível | Densidade exigida |
|---|---|
minimal | Use apenas quando o usuário solicitar explicitamente. Escreva um breve resumo seguido por aproximadamente 2–5 itens de resultado altamente consolidados, com no máximo um ou dois cabeçalhos quando melhorarem materialmente a varredura. Cubra apenas as mudanças definidoras visíveis ao usuário do release e avisos necessários. |
medium | Use apenas quando o usuário solicitar explicitamente. Escreva um resumo, um pequeno número de seções úteis e itens agrupados que cubram as principais funcionalidades, correções e resultados de segurança ou compatibilidade. Consolide fluxos de trabalho de suporte relacionados em vez de enumerar cada um separadamente. |
detailed | Padrão a menos que o usuário escolha explicitamente outro nível. Organize as notas por subsistema ou fluxo de trabalho significativo e dê a cada capacidade distinta visível ao usuário, mudança de comportamento, correção de compatibilidade, limitação suportada e resultado de desempenho ou validação verificado espaço suficiente para ser entendido sem ler o diff. Inclua fluxos de trabalho de suporte quando afetarem materialmente como os usuários entendem ou usam a mudança, mas não adicione preenchimento quando um release tiver menos mudanças reais. |
Trate os níveis como orientação de cobertura e agrupamento, não como modelos fixos. Determine o delta factual completo primeiro, depois consolide-o ao nível selecionado. Se o usuário disser apenas "escreva as notas de release" ou "prepare o release", use detailed.
Aplique ênfase específica do canal:
- Stable: Resuma o delta completo desde a tag stable anterior. Em cada bloco de idioma, comece com um breve resumo do release, depois use apenas seções úteis como
#### ✨ Highlights/#### ✨ 重点更新,#### 🛠️ Fixes/#### 🛠️ 修复,#### 🔒 Security/#### 🔒 安全, ou#### 🧰 Release Maintenance/#### 🧰 发布维护. Enfatize comportamento visível ao usuário e compatibilidade. O corpo do Release do GitHub composto deve começar com navegação[中文](#中文) | [English](#english), seguido pelo bloco completo### 中文e então o bloco correspondente### English, omita tanto um cabeçalho principal do produto como# OxideTerm 2.0quanto um cabeçalho de versão repetido como## 2.0.7, depois coloque## 📥 Download for your system, dicas de instalação e links após ambos os blocos de idioma. - Beta: Resuma o delta desde a tag beta anterior em blocos completos inglês e chinês. Declare o que está se aproximando do estável, o que mudou e quais fluxos de trabalho precisam de validação. Mencione limitações conhecidas apenas quando suportadas pelo diff ou contexto da issue, e inclua-as em ambos os idiomas.
- Preview GPUI: Resuma o delta desde a tag anterior de preview GPUI em blocos completos inglês e chinês. Foque em trabalho de UI/tempo de execução nativo recentemente testável, paridade, arestas ásperas e alvos de teste concretos. Aplique o nível de detalhe selecionado mantendo a redação orientada a teste em vez de transformar notas de preview em marketing de release estável.
Se não houver tag anterior para aquele canal, declare qual tag de release anterior foi usada como linha de base de inicialização.
4. Executar o script de versão do repositório
Sempre use o script do repositório; nunca edite manualmente a versão do workspace ou o lockfile:
python3 scripts/release/bump_version.py <versão>
Isso valida o SemVer, atualiza [workspace.package] e atualiza Cargo.lock offline. Os badges do README exibem o último release do GitHub automaticamente e não precisam de edições de versão.
5. Realizar validação leve do release
Não execute cargo test,
…
[truncado para tradução]