Capgo Verificador de Semver

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

Versión de Base Nativa

La versión nativa enviada a Capgo como version_build, desde la configuración o metadatos de la aplicación nativa.

Versión Remota

La versión del paquete asignada al canal resuelto.

Contexto de la Aplicación

Plataforma

Configuración de compilación protegida

Ejecutando en emulador

Configuración de canal

Desarrollo de iOS

Permitir actualizaciones para dispositivos iOS

Desarrollo de Android

Permitir actualizaciones para dispositivos Android

Permitir compilación de desarrollo

Permitir actualizaciones para compilaciones de desarrollo

Permitir emuladores

Permitir actualizaciones para dispositivos de emulador

Deshabilitar auto descenso bajo nativo

Evita descender cuando se ejecuta nativo code

Deshabilitar actualización automática

Mayor: bloquea la versión mayor del objetivo mayor que la versión_build. Permite 1.2.3 -> 1.9.0, bloquea 1.2.3 -> 2.0.0.

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

¿Qué significa "Versión de Base Nativa"?

Native Baseline Version is the native app version sent to Capgo as version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version de capacitor.config.*Si ese ajuste no está presente, el plugin cae en la versión de la aplicación nativa desde iOS o Android. No asuma que es tu package.json versión a menos que tu compilación copie ese valor en la configuración o en los metadatos nativos.

Capgo still uses version_name saber qué paquete descargado está instalado actualmente. major, minorpolicies de canal semver como patch , y version_build.

Capacitor config

__CAPGO_KEEP_0__ configuración CapacitorUpdater.version Establecer

cuando desee una versión explícita enviada por la aplicación. Ventaja:

fácil de mantener lo mismo en iOS y Android. Desventaja:

la configuración caducada puede informar la versión incorrecta si se olvida de actualizar antes de una liberación nativa.

Versión de la aplicación nativa CFBundleShortVersionString o Android versionName.

Ventaja: se ajusta a los binarios que los usuarios instalaron desde TestFlight, App Store, Play Store, o pruebas internas.

Desventaja: cambiarlo requiere una compilación nativa y puede diferir por plataforma si los ajustes de lanzamiento varían.

Diseño de paquete dirigido

Comparelo con versiones remotas de paquetes, reglas de semver de canal o restricciones de carga como --native-version.

Ventaja: evita enviar JavaScript que necesita una versión nativa code más nueva a binarios de aplicaciones antiguos.

Desventaja: las reglas demasiado estrictas pueden bloquear actualizaciones válidas hasta que se ajuste el canal o el metadato del paquete.

Para este tester, ingrese la base nativa que el dispositivo envía como version_buildEntonces, compara con la versión remota del paquete que deseas que Capgo entregue.

¿Por qué Capgo utiliza la Semántica de la Versión?

La Semántica de la Versión es el estándar de versionado más ampliamente adoptado en el desarrollo de software. Al utilizar semver, Capgo garantiza la compatibilidad y la seguridad al entregar actualizaciones en vivo a tus aplicaciones Capacitor.

El estándar semver permite a Capgo comprender exactamente qué cambios se incluyen en cada actualización:

Actualizaciones de parche (1.0.0 → 1.0.1): Correcciones de errores, seguras para aplicar automáticamente
Actualizaciones menores (1.0.0 → 1.1.0): Nuevas características, compatibles hacia atrás
Actualizaciones mayores (1.0.0 → 2.0.0): Cambios disruptivos, requieren lanzamiento nativo de tienda

Esto evita que Capgo envíe nunca una actualización incompatible a tu aplicación nativa code, protegiendo a tus usuarios de errores y asegurando que tu aplicación permanezca estable.

Estrategias Semver Flexibles: Más Allá de la Versión Básica

Si bien semver es estricto sobre su formato básico, puede extenderlo para las necesidades de su equipo utilizando identificadores de pre-lanzamiento y metadatos de construcción:

🏷️ Metadatos de Construcción (+) - La Capa "Cosmética"

1.2.0+20240315.142530

Fecha de tiempo de marcaje para seguimiento de despliegue

1.2.0+ui.refresh.dark-mode

Descripción de actualización de interfaz de usuario para el equipo de diseño

1.2.0+build.4729.commit.a1b2c3d

Número de construcción de CI/CD y commit de Git

Importante: Se ignora el metadatos de construcción en la versión de precedencia - 1.2.0+anything igual 1.2.0 para la lógica de actualización de Capgo.

🔧 Identificadores de versión prelanzamiento (-) - Canales de desarrollo

1.3.0-beta.1

Canales de prueba de beta

1.3.0-hotfix.payment

Rama de corrección urgente

1.3.0-feature.newapi

Rama de prueba de características

Nota: Las versiones prelanzamiento tienen una precedencia menor - 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 liberación con metadatos de interfaz de usuario y fecha de timestamp

Casos de uso de Semver en el mundo real y estrategias de equipo

🚀 Desarrollo rápido / Inicio de una startup

0.1.0 - Primer lanzamiento MVP

0.2.0-beta.1 - Pruebas de nuevas características

0.2.0+ui.v2 - Metadatos de diseño de interfaz de usuario

1.0.0 - Listo para producción

Utilice 0.x.x para desarrollo pre-1.0, metadatos para seguimiento de diseño

🏢 Empresa / Regulada

2.1.0 → Lanzamiento cuatrimestral

2.1.1+sec.patch.cve2024 → Actualización de parche con seguimiento

2.2.0-rc.1+audit.ready → Candidato a la auditoría previa

Strict semver con metadatos de cumplimiento

🎮 Aplicaciones de juegos / creativas

1.0.0+season.winter.2024 → Contenido estacional

1.1.0+event.halloween → Características impulsadas por eventos

1.2.0+assets.hd.remaster → Actualizaciones de activos

Metadatos creativos para el seguimiento del contenido

⚡ Estrategia de parche de emergencia

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 fecha de timestamp

Versión previa para pruebas, metadatos para el seguimiento de la implementación

Estrategia de múltiples plataformas 🌍

1.3.0+ios.optimized → Optimizaciones específicas de iOS

1.3.0+android.material3 → Actualizaciones de diseño para Android

1.3.0+web.pwa.ready → Capacidad de PWA

Misma versión, metadatos específicos de plataforma

🔄 Integración de CI/CD

1.4.0-alpha.1+build.123 → Despliegue automático de pre-establecimiento

1.4.0+deploy.staging.456 → Despliegue de etapa

1.4.0+prod.final.789 → Despliegue de producción

Versión automática con metadatos de implementación

💡 Consejos Pro:

Use build metadata (+) para el seguimiento, fechas y la información cosmética que no afecta la compatibilidad
Use identificadores de versión prelanzamiento (-) para los canales de desarrollo que necesitan una prioridad diferente de actualizaciones
Combina ambos para la máxima flexibilidad: 1.2.0-beta.1+ui.dark.theme.20240315
Recuerda: Capgo respeta las reglas de precedencia de semver, así que planifica tu estrategia de canal según corresponda

Importante: Capgo utiliza una versión semántica estricta

Diferente a la implementación de semver de npm, Capgo sigue estrictamente la especificación de SemVer. npm's node-semver tiene conocidas desviaciones de la especificación, lo que puede causar un comportamiento inesperado.

Por ejemplo, npm trata versiones como 1.0.0-alpha.1 diferentemente que lo requiere la especificación. Consulta nuestro informe de problema y intentos de solución que nunca se integraron.

Versiones Semánticas Válidas

1.0.0 ✓ Lanzamiento estándar

2.1.3-alpha ✓ Pre-lanzamiento

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

1.0.0+build.1 ✓ Metadatos de compilación

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

Versiones Semánticas Inválidas

v1.0.0 ✗ No se permite el 'v' inicial

1.0 ✗ Falta la versión de parche

1.0.0.0 ✗ Demasiados partes de versión

1.0.0- ✗ Pre-lanzamiento vacío

1.0.0+ ✗ Metadatos de compilación vacío

Capgo Actualización de Comportamiento

✓ La estrategia menor permite cambios de parche en la misma línea mayor.minor, por ejemplo 1.0.0 -> 1.0.1

✓ La estrategia de parche 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 de mayor bloquea paquetes de destino con un mayor mayor que la base nativa, por ejemplo 1.0.0 -> 2.0.0

⚠ La protección de downgrade utiliza la precedencia de semver completa, por lo que 1.0.0 estable es más nuevo que 1.0.0-beta.2

Esta herramienta sigue la especificación de Versión Semántica oficial diferente de la implementación de npm.