openclaw-release-maintainer

OpenClaw Release Maintainer

Use esta skill para fluxo de trabalho de lançamento e publicação. Mantenha alterações de desenvolvimento ordinárias e trabalho de advisory específico do GHSA fora desta skill.

Respeite as proteções de lançamento

• Não altere números de versão sem aprovação explícita do operador.
• Peça permissão antes de qualquer npm publish ou etapa de lançamento.
• Esta skill deve ser suficiente para conduzir o fluxo de lançamento normal de ponta a ponta.
• Use os documentos privados de mantenedor para credenciais, etapas de recuperação e detalhes de assinatura/notarização macOS, e use docs/reference/RELEASING.md para políticas públicas.
• A publicação do core openclaw é workflow_dispatch manual; criar ou enviar uma tag não publica por si só.
• O trabalho de lançamento normal ocorre em um branch cortado de main, não diretamente no main. Use release/YYYY.M.D para o nome do branch.
• Se o operador pedir um lançamento sem dizer stable/full, por padrão, apenas beta. Continue de beta para stable apenas quando o operador pedir explicitamente o lançamento completo ou um trem beta-e-stable automatizado.
• Antes de ramificar para lançamento, puxe o main mais recente e confirme que o CI atual do main está verde. Em seguida, ramifique a partir desse commit para que o desenvolvimento regular possa continuar em main enquanto a validação do lançamento é executada.
• Antes de ramificar para lançamento, commite quaisquer arquivos sujos em grupos coerentes, envie (push), puxe (pull)/rebaseie, depois execute /changelog em main e commit/envie/puxe essa reescrita do changelog imediatamente antes de criar o branch de lançamento.
• Durante o planejamento do lançamento, inspecione tanto src/plugins/compat/registry.ts quanto src/commands/doctor/shared/deprecation-compat.ts antes de ramificar e novamente antes da publicação final. Para cada registro de compatibilidade obsoleto ou com remoção pendente cuja data removeAfter seja igual ou anterior à data do lançamento, remova o caminho de compatibilidade onde for seguro e valide os testes afetados, ou escreva por que a remoção está bloqueada e obtenha aprovação explícita do mantenedor antes de enviar o caminho de compatibilidade expirado.
• Ao remover compatibilidade de runtime/config obsoleta, preserve qualquer migração, reparo ou dica do doctor que ainda seja necessária para caminhos de upgrade suportados. A compatibilidade do lado do doctor deve permanecer rastreada em src/commands/doctor/shared/deprecation-compat.ts até que os mantenedores confirmem que o reparo não é mais necessário.
• Revalide o texto de substituição de compatibilidade durante o planejamento do lançamento. A substituição recomendada pode mudar à medida que a propriedade do plugin, externalização e pegada de configuração se movem, então não copie cegamente anotações de substituição desatualizadas para as notas de lançamento.
• Não exclua ou reescreva tags beta após seu pacote npm correspondente ter sido publicado. Se uma tag beta enviada falhar antes da publicação npm, a versão não é consumida: mantenha o mesmo -beta.N, exclua/recrie ou force-mova a tag git e a pré-lançamento para o commit corrigido, e reexecute a pré-verificação. Não incremente para o próximo número beta até que o pacote npm correspondente tenha realmente sido publicado. Se um beta publicado precisar de uma correção, commite a correção no branch de lançamento e incremente para o próximo -beta.N.
• Para um trem de lançamento beta, execute a pré-verificação local rápida primeiro, publique o beta no npm beta, depois execute o caro roteiro de pacote publicado focado em install/update/Docker/Parallels/NPM Telegram. Se algo falhar, corrija no branch de lançamento, commit/envie/puxe, incremente o número beta e repita. Execute o caro roteiro completo pelo menos uma vez antes da promoção para stable/latest; para tentativas beta posteriores, reexecute apenas as pistas cujas evidências mudaram, a menos que a correção afete comportamento amplo de release, install/update, plugin, Docker, Parallels ou QA ao vivo. Após cada beta ser publicado, escaneie o main atual uma vez em busca de correções críticas que chegaram após o corte do branch de lançamento e faça backport apenas de correções importantes de baixo risco. Os operadores podem autorizar até 4 tentativas beta autônomas; após 4 tentativas beta falhadas, pare e reporte.
• Use /changelog antes da preparação de versão/tag para que a seção superior do changelog seja deduplicada e ordenada por impacto no usuário.
• Não crie cabeçalhos CHANGELOG.md específicos para beta. Lançamentos beta usam a seção de versão base estável, por exemplo v2026.4.20-beta.1 usa notas de lançamento ## 2026.4.20.
• Quando qualquer lançamento beta ou estável estiver ativo, faça um anúncio no Discord de melhor esforço usando o fluxo secreto configurado; não bloqueie ou reverta o lançamento se o anúncio falhar.
• Quando for solicitado a anunciar no X, use ~/Projects/bird/bird e siga o estilo de tweet de lançamento abaixo.

Mantenha a nomeação do canal de lançamento alinhada

• stable: apenas versões tagueadas, publicadas no npm beta por padrão; operadores podem mirar npm latest explicitamente ou promover depois
• beta: tags de pré-lançamento como vYYYY.M.D-beta.N, com dist-tag npm beta
• Prefira -beta.N; não crie novos sufixos beta -1 ou -2
• dev: cabeça móvel em main
• Ao usar uma tag Git beta, publique npm com o sufixo de versão beta correspondente para que a versão simples não seja consumida ou bloqueada

Lide com versões e arquivos de lançamento consistentemente

• Locais de versão incluem:
  • package.json
  • apps/android/app/build.gradle.kts
  • apps/ios/Sources/Info.plist
  • apps/ios/Tests/Info.plist
  • apps/macos/Sources/OpenClaw/Resources/Info.plist
  • docs/install/updating.md
  • Campos de versão do projeto Xcode e plist do Peekaboo
• Antes de criar uma tag de lançamento, faça com que cada local de versão acima corresponda à versão codificada por essa tag.
• Para tags de correção de fallback como vYYYY.M.D-N, os locais de versão do repositório ainda permanecem em YYYY.M.D.
• "Atualizar versão em todos os lugares" significa todos os locais de versão acima, exceto appcast.xml.
• Credenciais de assinatura de lançamento e notarização estão fora do repositório, nos documentos privados do mantenedor.
• Cada lançamento estável do OpenClaw envia o pacote npm e o aplicativo macOS juntos. Lançamentos beta normalmente enviam artefatos npm/pacote primeiro e pulam a construção/assinatura/notarização do aplicativo mac, a menos que o operador solicite validação beta mac.
• Não deixe que o caminho mais lento de assinatura/notarização macOS bloqueie a publicação npm assim que a pré-verificação npm for aprovada. Mantenha a validação/publicação mac em execução em paralelo, publique npm a partir da pré-verificação npm bem-sucedida, depois inicie a verificação de install/update npm, Docker e Parallels publicada enquanto os artefatos mac continuam.
• Após um beta ser publicado, sobreponha roteiros de lançamento remotos/manuais onde útil, mas evite empilhar trabalho local de Docker, Parallels e QA-Lab no mesmo host quando isso criar ruído de carga do sistema. Use reexecuções seletivas após falhas ou correções, mas mantenha prova de que Docker, Parallels e QA-Lab passaram pelo menos uma vez antes da promoção para stable/latest.
• O empacotamento Mac pode ser construído a partir de uma ligeira variação do branch de lançamento do commit tageado quando o delta é empacotamento mac, assinatura, fluxo de trabalho ou maquinário de lançamento apenas de validação. Se o empacotamento mac precisar de correções apenas no branch de lançamento após o pacote npm estável ou tag GitHub já ter sido publicado, não crie uma tag de correção vYYYY.M.D-N apenas para alterar a fonte do fluxo de trabalho. Despache os fluxos de trabalho mac privados para o tag=vYYYY.M.D original com source_ref=release/YYYY.M.D e public_release_branch=release/YYYY.M.D; verificações de proveniência devem provar que o SHA de origem descendente da tag e a validação/pré-verificação usam a mesma fonte. Reserve tags de correção vYYYY.M.D-N para hotfixes de emergência que devem publicar um novo pacote npm/identidade de lançamento, não para recuperação de empacotamento apenas mac ordinária.
• O feed Sparkle de produção reside em https://raw.githubusercontent.com/openclaw/openclaw/main/appcast.xml, e o arquivo canônico publicado é appcast.xml no main do repositório openclaw.
• Esse feed Sparkle de produção compartilhado é apenas estável. Lançamentos mac beta podem fazer upload de ativos para o pré-lançamento GitHub, mas não devem substituir o appcast.xml compartilhado a menos que exista um feed beta separado.
• Para tags de correção de fallback como vYYYY.M.D-N, a versão do repositório ainda permanece em YYYY.M.D, mas o lançamento mac deve usar um APP_BUILD / build Sparkle estritamente maior numericamente do que o lançamento original, para que as instalações existentes o vejam como mais novo.

Crie notas de lançamento baseadas em changelog

• Antes de ramificar para lançamento ou taguear, reescreva a seção CHANGELOG.md alvo a partir do histórico de commits, não apenas de notas existentes: escaneie commits desde a última tag de lançamento acessível, adicione alterações voltadas ao usuário perdidas, deduplique entradas sobrepostas e ordene cada seção da mais para a menos interessante para os usuários.
• As entradas do changelog devem ser voltadas ao usuário, não notas internas do processo de lançamento.
• Os corpos do release e prerelease do GitHub devem usar a seção de versão completa correspondente do CHANGELOG.md, não destaques ou um trecho. Ao criar ou editar um lançamento, extraia de ## YYYY.M.D até a linha antes do próximo cabeçalho de nível 2 e use esse bloco completo como as notas de lançamento.
• Ao preparar notas de lançamento, escaneie src/plugins/compat/registry.ts e src/commands/doctor/shared/deprecation-compat.ts em busca de registros de compatibilidade com warningStarts ou removeAfter dentro de 7 dias após a data do lançamento. Adicione uma nota Deprecações futuras às notas de lançamento quando alguma existir, incluindo o código de compatibilidade, data alvo, substituição e um link para o docsPath do registro ou /plugins/compatibility quando não existir uma página de deprecação mais específica.
• Ao cortar um lançamento mac com um pré-lançamento GitHub beta:
  • tague vYYYY.M.D-beta.N a partir do commit de lançamento
  • crie um prerelease intitulado openclaw YYYY.M.D-beta.N
  • use notas de lançamento da seção de versão base estável do CHANGELOG.md (## YYYY.M.D), não um cabeçalho específico beta
  • anexe pelo menos o zip e o zip dSYM, além de dmg se disponível
• Mantenha as entradas de versão superiores em CHANGELOG.md ordenadas por impacto:
  • ### Changes primeiro
  • ### Fixes deduplicado com correções voltadas ao usuário primeiro

Escreva tweets de lançamento

Use o estilo de post de lançamento existente da conta OpenClaw:

• Formato: OpenClaw YYYY.M.D 🦞 ou 🦞 OpenClaw YYYY.M.D is live, linha em branco, então 3-4 marcadores com emoji, linha em branco, uma linha de efeito curta, então o link do lançamento.
• Para beta: diga OpenClaw YYYY.M.D-beta.N 🦞 ou OpenClaw YYYY.M.D beta N is live; mantenha claramente beta e evite implicar promoção para estável.
• Lidere com capacidades visíveis ao usuário, depois integrações importantes, depois correções de confiabilidade/segurança/instalação. Comprima "muitas correções" em um marcador legível.
• Leia a seção completa do changelog antes de rascunhar. Não lidere com cobertura, CI, validação ou mecânicas internas de lançamento, a menos que o lançamento seja explicitamente sobre isso. Peter prefere vitórias concretas do usuário: funcionalidades, integrações, melhorias de fluxo de trabalho e correções práticas de confiabilidade.
• Não destaque paridade de QA, cobertura de teste, gates de lançamento ou pistas de validação em tweets de lançamento voltados ao usuário. Mantenha-os para notas de lançamento ou prova do mantenedor, a menos que o operador peça explicitamente por cópia focada em validação.
• Não destaque autor de plugin ou ferramentas de desenvolvedor, como helpers SDK, scaffolding de ferramenta-plugin, comandos de build/validate/init ou encanamento CLI interno em tweets de lançamento voltados ao usuário em geral, a menos que o operador peça explicitamente por cópia focada em desenvolvedor.
• Tom: alto sinal, ligeiramente atrevido, confiante, não corporativo. Uma piada é suficiente. Evite menosprezar, insultar usuários ou prometer o que não foi verificado.
• Peter gosta de taglines secas e compactas quando parecem merecidas. Bom exemplo: Grande lançamento, notas de lançamento pequenas... brincadeira. Mantenha a piada curta e deixe os marcadores de funcionalidade carregarem o tweet; não transforme a linha de efeito em um segundo parágrafo ou uma forçação de barra.
• Comprimento: tweets de lançamento são sempre tweets padrão com menos de 280 caracteres, com espaço para uma URL. Corte para 3-4 marcadores e conte o texto final antes de postar.
• Links/mídia: inclua o link do release GitHub ou changelog no final do primeiro tweet de lançamento.
• Acompanhamentos em thread: se fizer uma thread, mantenha o primeiro tweet de lançamento como o post compacto de lançamento, então publique um explicador de funcionalidade focado por resposta. Respostas de acompanhamento não devem repetir "novo em VERSION" ou o número da versão quando o contexto da thread já o torna óbvio.
• Fluxo de trabalho de thread preferido de Peter: primeiro concorde com o tweet de lançamento genérico, então prossiga através dos tweets de acompanhamento um por um. Quando ele disser next, forneça ou copie o próximo acompanhamento apenas; não despeje a thread completa novamente a menos que solicitado.
• Cada tweet de acompanhamento deve incluir uma URL de docs para essa funcionalidade específica. Prefira uma URL nua em vez de Docs: <url> a menos que o rótulo seja necessário para clareza. Mantenha os acompanhamentos concisos: cerca de 160-220 caracteres brutos é geralmente o ponto ideal; abaixo de 280 é o limite máximo. Se uma URL fizer um tweet falhar, corte prosa antes de descartar a URL. Prefira explicar diagnósticos, trajetória/exportação, configuração de provedor, comandos de modelo, ou outras funcionalidades pesadas de configuração em acompanhamentos em vez de sobrecarregar o primeiro tweet de lançamento.
• Hotfix/correção: seja direto e responsável. Declare o que passou, o que está corrigido e a nova versão. Mantenha piadas fora de posts de estilo de incidente.

Exemplos para adaptar:

OpenClaw 2026.4.20-beta.1 🦞

🐳 Smoke de install/update Docker
🖥️ Verificações de upgrade Parallels
🔧 Verificação de pacote apertada

Beta primeiro. Estável depois do desafio.
<release link>

OpenClaw 2026.4.20 🦞

🚀 Install + update mais rápidos
🐳 Docker + Parallels verificados
🍎 macOS assinado + notarizado
🔧 Correções de canal/plugin

Bom lançamento chato. Melhor tipo.
<release link>

Problema de empacotamento no 2026.4.20-beta.1.

2026.4.20-beta.2 corrige verificação de install/update. Sem reescritas de tag; beta avança.

Atualize com o canal beta.
<release link>

Execute validação no momento da publicação

Antes de taguear ou publicar, execute:

pnpm check:architecture
pnpm build
pnpm ui:build
pnpm qa:otel:smoke
pnpm release:check
pnpm test:install:smoke

• Use pnpm qa:otel:smoke quando a validação do lançamento precisar de cobertura de telemetria. Inicia um receptor local de rastreamento OTLP/HTTP, executa o otel-trace-smoke do QA-lab, e verifica nomes de span e redação de conteúdo/identificador sem Opik externo ou

…

[truncado para tradução]