​

Processo de Release

Esta página descreve o fluxo de release atual do repositório, não um pipeline idealizado de estado futuro.

​

Modelo de entrega atual

• Pull requests são a unidade de entrega.
• O GitHub Actions é a fonte de verdade para as verificações do repositório.
• apps/web, apps/app e apps/api são implantados via Vercel na postura alpha atual.
• apps/worker é implantado por meio de um deployment no estilo Railway.
• Tags semver são usadas para releases deliberados.
• O buildVersion em runtime é distinto da versão de release semver.

​

Verificações padrão atuais

O repositório valida:

• lint
• lint de docs
• higiene de docs
• desvio (drift) da especificação OpenAPI
• higiene de release
• build de docs
• typecheck
• testes
• build

Workflows adicionais de hardening, como revisão de dependências e CodeQL, existem, mas podem depender do plano/configuração do repositório.

​

Política de trem de release

Até a fase alpha, o Switchbord usa semver de trem de release:

• patch para correções, correções de documentação e higiene de release
• minor para ondas coerentes de capacidade
• major apenas para a semântica estável de 1.0.0

Não crie uma versão minor para cada PR. Uma versão deve explicar um estado coerente do repositório.

​

Etapas obrigatórias de release

Para todo release deliberado:

1. Atualize o package.json para a versão pretendida.
2. Atualize o CHANGELOG.md com ## vX.Y.Z e datas factuais respaldadas pelo git.
3. Atualize o MDX do changelog público na web, se o release for voltado ao cliente.
4. Atualize a documentação Mintlify para qualquer feature visível ao usuário ou mudança de comportamento operacional.
5. Execute:
   pnpm release:hygiene
   pnpm lint
   pnpm --filter docs docs:hygiene
   pnpm typecheck
   pnpm test
   pnpm build
   
6. Faça o merge do PR de release.
7. Marque exatamente a mesma versão com tag:
   pnpm release:tag
   pnpm release:tag:push
   
8. Confirme que o GitHub Release foi criado para a tag correspondente.

​

Marcação retroativa de tags históricas

Versões históricas da fase alpha, antes desta política, não foram marcadas com tags de forma consistente. Não fabrique tags. Se a marcação retroativa for necessária antes da fase alpha:

1. Identifique o commit exato que representava aquele estado de release.
2. Verifique o package.json e o CHANGELOG.md naquele commit.
3. Crie a tag histórica apenas se a evidência for inequívoca.
4. Prefira iniciar a correspondência estrita no próximo trem de release se o limite histórico não estiver claro.

​

Orientação para contribuidores

• Não assuma que uma feature está pronta para release apenas porque ela builda localmente.
• Se sua mudança altera o comportamento em runtime, atualize tanto a documentação Mintlify quanto a documentação operacional do repositório que descreve o mesmo contrato.
• Se sua mudança afeta o estado público de marketing, atualize o changelog da web ou declare explicitamente por que não, no corpo do PR.
• Se uma data de changelog não for respaldada por git log ou gh pr view, não faça o commit dela.
• Se uma mudança exigir novos gates de CI, documente isso como um follow-up explícito em vez de sugerir que já existe.

​

Hardening planejado

Estas são adições esperadas, mas devem ser descritas como planejadas até estarem ativas no CI:

• builds de container para runtimes de longa duração
• validação de migrações
• verificações de ambiente mais estritas
• política de promoção de ambiente de release

​

Leia a seguir

• Versionamento
• CI/CD
• Fluxo de Contribuição