Lançamento de versões do Oleafly

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.

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 (abre em uma nova guia). 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 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.