Publicar una versión de Oleafly

Las versiones de Oleafly tienen dos etapas deliberadas. Una etiqueta de versión genera y verifica un borrador. Una persona mantenedora publica ese mismo borrador con una ejecución de flujo de trabajo distinta.

Subir cambios a main ejecuta CI, pero no crea una versión.

Generar el borrador

Parte de una rama main actualizada y con CI en 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

La etiqueta inicia .github/workflows/release.yml. Este flujo genera los siguientes destinos:

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

Cada destino descarga y verifica sus sidecars de compilador fijados. Después, el flujo combina los cuatro fragmentos del actualizador en un único latest.json. El borrador se considera listo solo cuando están presentes todos los instaladores y entradas del actualizador necesarios.

Revisar el borrador

Abre el borrador en la página de Releases de GitHub (se abre en una pestaña nueva). Comprueba las notas de la versión, los nombres de los instaladores, las sumas de verificación, las firmas y latest.json. No publiques un borrador incompleto.

Publicar

Abre Actions → Release → Run workflow. Introduce la misma etiqueta y selecciona Publish the release.

La ejecución de publicación repite la compilación y las comprobaciones de artefactos. También ejecuta pruebas de contrato en vivo contra Anthropic y Google con la versión candidata. El trabajo final se niega a publicar a menos que estén presentes todas las plataformas admitidas y el feed completo del actualizador.

Al publicar, latest.json pasa a ser visible para las apps instaladas. Trátalo como una acción irreversible en producción. Si la ejecución de publicación falla, deja la versión como borrador, corrige la causa y vuelve a ejecutarla.

Números de versión

Oleafly sigue el versionado semántico:

• Parche, como de 0.3.5 a 0.3.6, para correcciones compatibles.
• Menor, como de 0.3.5 a 0.4.0, para funciones compatibles.
• Mayor, como de 0.3.5 a 1.0.0, para cambios incompatibles o la primera versión estable.

Comprobaciones importantes

• La etiqueta debe coincidir con package.json, src-tauri/tauri.conf.json, src-tauri/Cargo.toml y src-tauri/Cargo.lock. Usa scripts/bump-version.sh en lugar de editarlos por separado.
• Las notas de la versión salen de la sección de la versión correspondiente en CHANGELOG.md.
• No reutilices una etiqueta ya publicada. Si un borrador falla, corrige la rama y crea una versión nueva, salvo que haya un motivo claro para reemplazar la etiqueta sin publicar.
• La firma y la notarización de macOS usan los secretos de lanzamiento de Apple. Authenticode de Windows usa Azure Artifact Signing cuando sus secretos están configurados. Las firmas del actualizador usan la clave de firma de Tauri, que es aparte.

Consulta Actualizaciones automáticas para la firma del actualizador y el comportamiento de reversión. Las instrucciones de instalación para usuarios están en Descarga e instalación.