Saltar al contenido principal

Capgo Semver Tester

Comprueba la compatibilidad de la política del canal con la base nativa enviada como version_build

La versión nativa enviada a Capgo como version_build, desde la config o los metadatos de la app nativa.

La versión del bundle asignada al canal resuelto.

Introduce dos versiones semánticas para compararlas

Qué significa "Native Baseline Version"

La Native Baseline Version es la versión de la app nativa enviada a Capgo como version_build cuando el dispositivo solicita un bundle al servidor de actualizaciones. En una app con Capacitor, ese valor puede venir de CapacitorUpdater.version en capacitor.config.*. Si ese ajuste no está presente, el plugin usa la versión de la app nativa de iOS o Android. No asumas que es tu package.json versión a menos que tu build copie ese valor en la config o en los metadatos nativos.

Capgo sigue usando version_name para saber qué bundle descargado está instalado. Las políticas de semver de un Channel como major, minor, y patch comparan el bundle remoto contra version_build.

la config de Capacitor

Configúralo CapacitorUpdater.version cuando quieras enviar una versión explícita desde la app.

Pro: es fácil mantener la misma en builds de iOS y Android.

Contra: una config desactualizada puede reportar la versión incorrecta si olvidas actualizarla antes de un Native Build.

Versión de la app nativa

Usa la versión de la plataforma, como iOS CFBundleShortVersionString o Android versionName.

Pro: coincide con el binario que los usuarios instalaron desde TestFlight, App Store, Play Store o pruebas internas.

Contra: cambiarlo requiere un Native Build y puede variar según la plataforma si la configuración de release cambia.

Destino del bundle

Compara con versiones de bundle remotas, reglas de semver del canal o restricciones de upload de metadatos como --min-update-version. El canal debe usar --disable-auto-update metadata.

Pro: evita enviar JavaScript que requiere un code nativo más reciente a binarios de apps antiguos.

Contra: reglas demasiado estrictas pueden bloquear actualizaciones válidas hasta ajustar el canal o los metadatos del bundle.

Para este tester, introduce la base nativa que envía el dispositivo como version_build, y compárala con la versión del bundle remoto que quieres que Capgo entregue.

Por qué Capgo usa Semantic Versioning

Versionado semántico es el estándar de versionado más adoptado en el desarrollo de software. Al usar semver, Capgo garantiza compatibilidad y seguridad al enviar Live Update a tus apps Capacitor.

El estándar semver permite que Capgo entienda exactamente qué cambios incluye cada actualización:

  • Parches (1.0.0 → 1.0.1): Corrección de bugs, seguros para aplicar automáticamente
  • Updates menores (1.0.0 → 1.1.0): New features, backward compatible
  • Updates mayores (1.0.0 → 2.0.0): Breaking changes, requieren release en la app store

Esto evita que Capgo envíe una actualización incompatible a tu code nativo, protegiendo a tus usuarios de crashes y asegurando la estabilidad de tu app.

Estrategias de Semver flexibles: más allá del versionado básico

Aunque semver es estricto con su formato base, puedes extenderlo según las necesidades de tu equipo usando identificadores de pre-release y metadatos del build:

🏷️ Build Metadata (+) - La capa "cosmética"

1.2.0+20240315.142530
Timestamp para seguimiento de despliegues
1.2.0+ui.refresh.dark-mode
UI update description for design team
1.2.0+build.4729.commit.a1b2c3d
Número de build de CI/CD y commit de git

Importante: Se ignora el metadato de build en la precedencia de versiones - 1.2.0+anything es igual a 1.2.0 para la lógica de actualización de Capgo.

🔧 Identificadores de pre-release (-) - Canales de desarrollo

1.3.0-beta.1
Canal de pruebas beta
1.3.0-hotfix.payment
Rama de corrección urgente
1.3.0-feature.newapi
Pruebas de rama de feature

Nota: Las versiones pre-release tienen menor precedencia - 1.3.0-beta.1 < 1.3.0

🎯 Enfoque híbrido - Lo mejor de ambos mundos

1.3.0-rc.1+ui.redesign.20240315
Release candidate con metadata de UI y timestamp

Casos de uso de Semver y estrategias de equipo

🚀 Startup / Desarrollo rápido

0.1.0 - Primer lanzamiento MVP
0.2.0-beta.1 - Testing de nuevas features
0.2.0+ui.v2 - Metadata de rediseño de UI
1.0.0 - Listo para producción

Usa 0.x.x para desarrollo pre-1.0 y metadata para tracking de diseño

🏢 Enterprise / Regulado

2.1.0 → Lanzamiento trimestral
2.1.1+sec.patch.cve2024 → Parche de seguridad con tracking
2.2.0-rc.1+audit.ready → Release candidate pre-auditoría

Semver estricto con metadata de compliance

🎮 Apps de Gaming / Creativas

1.0.0+season.winter.2024 → Contenido estacional
1.1.0+event.halloween → Funciones basadas en eventos
1.2.0+assets.hd.remaster → Actualización de assets

Metadatos creativos para tracking de contenido

⚡ Estrategia de Hotfix

1.2.0 → Producción actual
1.2.1-hotfix.payment → Corrección de bug crítico
1.2.1+urgent.20240315.1430 → Lanzado con timestamp

Pre-release para testing y metadatos de despliegue

🌍 Estrategia Multi-Platform

1.3.0+ios.optimized → Optimizaciones específicas de iOS
1.3.0+android.material3 → Actualizaciones de diseño en Android
1.3.0+web.pwa.ready → Capacidades de PWA

Misma versión, metadatos por plataforma

🔄 Integración CI/CD

1.4.0-alpha.1+build.123 → Pre-release automatizado
1.4.0+deploy.staging.456 → Despliegue en Staging
1.4.0+prod.final.789 → Despliegue en Producción

Versionado automático con metadatos de despliegue

💡 Consejos pro:
  • Usa build metadata (+) para tracking, timestamps o info cosmética que no afecte la compatibilidad
  • Usa pre-release identifiers (-) para canales de desarrollo con distinta precedencia de updates
  • Combina ambos para máxima flexibilidad: 1.2.0-beta.1+ui.dark.theme.20240315
  • Recuerda: Capgo respeta las reglas de precedencia de semver; planifica tu estrategia de canales en consecuencia

Importante: Capgo utiliza versionado semántico estricto

A diferencia de la implementación de semver de npm, Capgo sigue estrictamente la especificación oficial de SemVer. El node-semver de npm tiene desviaciones conocidas de la especificación, lo que puede causar un comportamiento inesperado.

Por ejemplo, npm trata las versiones como 1.0.0-alpha.1 de forma distinta a lo que requiere la especificación. Consulta nuestro issue reportado y fix intentado que nunca se mergeó.

Versiones Semánticas Válidas

1.0.0 ✓ Release estándar
2.1.3-alpha ✓ Pre-release
1.0.0-beta.1 ✓ Pre-release con número
1.0.0+build.1 ✓ Metadatos del build
1.0.0-rc.1+build.1 ✓ Versión completa

Versiones SemVer inválidas

v1.0.0 ✗ No se permite el prefijo 'v'
1.0 ✗ Falta la versión patch
1.0.0.0 ✗ Demasiados segmentos de versión
1.0.0- ✗ Pre-release vacío
1.0.0+ ✗ Build metadata vacío

Comportamiento de las actualizaciones de Capgo

✓ La estrategia Minor permite cambios de patch en la misma línea major.minor, ej: 1.0.0 -> 1.0.1
✓ La estrategia Patch bloquea 1.0.0 -> 1.0.1. Solo permite cambios de sufijo como 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Las estrategias principales bloquean bundles con un major superior al baseline nativo, ej: 1.0.0 -> 2.0.0
⚠ La protección contra downgrade usa precedencia semver completa; la 1.0.0 estable es más nueva que 1.0.0-beta.2

Esta herramienta sigue la especificación oficial de Especificación de Semantic Versioning a diferencia de la implementación de npm.