Probador de Semver de Capgo

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

Versión de la baseline nativa

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

Versión remota

La versión del bundle asignada al canal resuelto.

Introduce dos versiones semánticas para ver la comparación

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 pide 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 recurre a la versión nativa de la app en 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 semver de un Channel como major, minor, y patch comparan el bundle remoto contra version_build.

la config de Capacitor

Configurar CapacitorUpdater.version cuando quieres que la app envíe una versión explícita.

Pro: fácil de mantener igual en builds de iOS y Android.

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

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 build nativo y puede variar según la plataforma si la configuración de release se desajusta.

Segmentación del bundle

Compáralo con versiones de bundle remotas, reglas semver de canales o restricciones de metadatos para upload, como --min-update-version. El canal debe usar --disable-auto-update metadata.

Pro: evita enviar JavaScript que requiera un code nativo más nuevo a binarios de app antiguos.

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

Para este tester, introduce la línea base nativa que el dispositivo envía como version_build, y luego 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 la compatibilidad y la seguridad al entregar actualizaciones en vivo a tus apps Capacitor.

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

Actualizaciones de parche (1.0.0 → 1.0.1): Bug fixes, safe to apply automatically
Actualizaciones menores (1.0.0 → 1.1.0): Nuevas funcionalidades, retrocompatibles
Actualizaciones mayores (1.0.0 → 2.0.0): Breaking changes, requieren un release nativo 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 que tu app se mantenga estable.

Estrategias flexibles de Semver: 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 de build:

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

1.2.0+20240315.142530

Timestamp para el 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: Los metadatos de build se ignoran en la precedencia de versión - 1.2.0+anything es igual a 1.2.0 para la lógica de actualización de Capgo.

🔧 Identificadores de prelanzamiento (-) - 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 feature

Nota: Las versiones de prelanzamiento 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

Candidato a release con metadatos 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

🎮 Gaming / Apps creativas

1.0.0+season.winter.2024 → Contenido estacional

1.1.0+event.halloween → Funciones basadas en eventos

1.2.0+assets.hd.remaster → Actualizaciones 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, metadatos para tracking de despliegue

🌍 Estrategia multiplataforma

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 afecta la compatibilidad
Usa identificadores pre-release (-) para canales de desarrollo que necesitan distinta precedencia de actualizaciones
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 en consecuencia tu estrategia de canales

Importante: Capgo usa 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 comportamientos inesperados.

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 intento de fix que nunca se mergeó.

Versiones semánticas válidas

1.0.0 ✓ Release estándar

2.1.3-alpha ✓ Pre-lanzamiento

1.0.0-beta.1 ✓ Pre-release con número

1.0.0+build.1 ✓ Metadatos de build

1.0.0-rc.1+build.1 ✓ Versión completa

Versiones semánticas 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+ ✗ Metadatos de build vacíos

Comportamiento de actualización de Capgo

✓ La estrategia Minor permite cambios de patch en la misma línea major.minor, por ejemplo 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.

✗ La estrategia Major bloquea bundles de destino con un major superior al baseline nativo, por ejemplo 1.0.0 -> 2.0.0

⚠ La protección contra downgrade usa la precedencia semver completa, así que la 1.0.0 estable es más reciente que la 1.0.0-beta.2

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