# Lançamento de versões do Oleafly

Construa um rascunho completo a partir de uma tag de versão, revise cada artefato de plataforma e publique pelo fluxo de trabalho protegido de release.

Os releases do Oleafly têm duas etapas deliberadas. Uma tag de versão constrói e verifica um rascunho. Um mantenedor publica esse mesmo rascunho com uma execução separada do fluxo de trabalho.

Enviar commits para o `main` executa o CI, mas não cria um release.

## Construir o rascunho

Comece de um ramo `main` atualizado com o CI verde.

```sh
git switch main
git pull --ff-only
./scripts/bump-version.sh 0.3.6
git commit -am "chore: release v0.3.6"
git push origin main
git tag v0.3.6
git push origin v0.3.6
```

A tag dispara o `.github/workflows/release.yml`. Ele constrói estes destinos:

| Destino | Instaladores |
|---|---|
| macOS Apple Silicon | `.dmg` |
| Windows x64 | `.msi` e `-setup.exe` |
| Linux x64 | `.AppImage` e `.deb` |
| Linux ARM64 | `.AppImage` e `.deb` |

Cada destino baixa e verifica os sidecars de compilador fixados. O fluxo de trabalho então mescla os quatro fragmentos do atualizador em um único `latest.json`. O rascunho é considerado pronto somente quando todo instalador exigido e toda entrada do atualizador estão presentes.

## Revisar o rascunho

Abra o rascunho na [página de releases do GitHub](https://github.com/Oleafly/Oleafly/releases). Confira as notas de versão, os nomes dos instaladores, os checksums, as assinaturas e o `latest.json`. Não publique um rascunho parcial.

## Publicar

Abra **Actions → Release → Run workflow**. Informe a mesma tag e selecione **Publish the release**.

A execução de publicação repete o build e as verificações de artefatos. Ela também executa testes de contrato ao vivo contra a Anthropic e a Google usando o release candidate. O job final se recusa a publicar a menos que toda plataforma suportada e o feed completo do atualizador estejam presentes.

Publicar torna o `latest.json` visível aos aplicativos instalados. Trate isso como uma ação de produção irreversível. Se a execução de publicação falhar, deixe o release como rascunho, corrija a causa e execute de novo.

## Números de versão

O Oleafly segue o versionamento semântico:

- **Patch**, como de `0.3.5` para `0.3.6`, para correções compatíveis.
- **Minor**, como de `0.3.5` para `0.4.0`, para funcionalidades compatíveis.
- **Major**, como de `0.3.5` para `1.0.0`, para mudanças que quebram compatibilidade ou o primeiro release estável.

## Verificações importantes

- A tag precisa corresponder ao `package.json`, ao `src-tauri/tauri.conf.json`, ao `src-tauri/Cargo.toml` e ao `src-tauri/Cargo.lock`. Use o `scripts/bump-version.sh` em vez de editá-los separadamente.
- As notas de versão vêm da seção da versão correspondente no `CHANGELOG.md`.
- Não reutilize uma tag publicada. Para um rascunho que falhou, corrija o ramo e crie uma nova versão, a menos que haja um motivo claro para substituir a tag não publicada.
- A assinatura e a notarização do macOS usam os segredos de release da Apple. O Authenticode do Windows usa Azure Artifact Signing quando os segredos dele estão configurados. As assinaturas do atualizador usam a chave de assinatura separada do Tauri.

Veja [Atualizações automáticas](/docs/engineering/updates/) para a assinatura do atualizador e o comportamento de reversão. As instruções de instalação para o usuário estão em [Baixar e instalar](/docs/install/).