Capgo Prueba de Semver

Verificar compatibilidad con la política del 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 los metadatos de la aplicación nativa.

Versión Remota

La versión del paquete asignada al canal resuelto.

Contexto de la Aplicación

Plataforma

Edición de Desarrollo

Ejecutando en Emulador

Configuración de Canal

iOS

Permitir actualizaciones para dispositivos iOS

Android

Permitir actualizaciones para dispositivos Android

Permitir edición de desarrollo

Permitir actualizaciones para ediciones de desarrollo

Permitir emuladores

Permitir actualizaciones para dispositivos de emulación

Deshabilitar la actualización automática bajo nativo

Evita la actualización hacia atrás cuando se ejecuta nativo code

Deshabilitar la actualización automática

Mayor: bloquea la versión mayor 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 Baseline Nativa"?

La Versión de Baseline Nativa es la versión de la aplicación nativa enviada a Capgo como version_build cuando el dispositivo solicita al servidor de actualizaciones un paquete. En una aplicación Capacitor, ese valor puede provenir de CapacitorUpdater.version en capacitor.config.*Si ese ajuste no está presente, el plugin recae en la versión de la aplicación nativa de 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 metadatos nativos.

Aún así, Capgo utiliza version_name saber qué paquete descargado está instalado actualmente. major, minor, y patch comparar el paquete remoto contra version_build.

Capacitor configuración

Establecer CapacitorUpdater.version cuando desee una versión explícita enviada por la aplicación.

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

Desventaja: la configuración caducada puede informar la versión incorrecta si se olvida de actualizarla antes de una versión nativa.

Versión de la aplicación nativa

Usar la versión del sistema, como iOS CFBundleShortVersionString o Android versionName.

Ventajas: coincide con la versión binaria que los usuarios instalaron desde TestFlight, App Store, Play Store o pruebas internas.

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

Configuración de paquete

Comparezla con versiones de paquetes remotos, reglas de semver de canal, o restricciones de subida de metadatos como --min-update-versionEl canal debe utilizar --disable-auto-update metadata.

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

Desventajas: las reglas demasiado estrictas pueden bloquear actualizaciones válidas hasta que se ajuste el canal o los metadatos de paquete.

For este tester, ingresa la versión base nativa que el dispositivo envía como version_build, luego compara con la versión de paquete remoto que deseas Capgo entregar.

¿Por qué Capgo utiliza la versión semántica?

Versión semántica 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 una versión nativa de la tienda de aplicaciones

Esta función impide que Capgo envíe nunca una actualización incompatible a tu nativo code, protegiendo a tus usuarios de los errores y asegurando que tu aplicación permanezca estable.

Estrategias de Semver Flexibles: Más Allá de la Versionado Básico

Mientras que semver es estricto sobre su formato básico, puedes extenderlo para las necesidades de tu equipo utilizando identificadores de versión previa y contexto: Página/área: Sitio web de marketing de Capgo. Rol: Etiqueta de UI corta o elemento de navegación. Visto en: página trust.astro. Clave de mensaje `and` (Y).:

metadatos de construcción

1.2.0+20240315.142530

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

Timestamp para el seguimiento de la implementación

1.2.0+ui.refresh.dark-mode

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

1.2.0+build.4729.commit.a1b2c3d

Importante: El metadatos de compilación se ignora en la precedencia de versión - 1.2.0+anything igual que 1.2.0 para Capgo's lógica de actualización.

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

1.3.0-beta.1

Canal de prueba de beta

1.3.0-hotfix.payment

Rama de corrección urgente

1.3.0-feature.newapi

Rama de prueba de nueva funcionalidad

Nota: 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.rediseño.20240315

Candidato a lanzamiento con metadatos de interfaz de usuario y fecha de timestamp

Uso real del semver y estrategias de equipo

🚀 Arranque rápido / Desarrollo rápido

0.1.0 - Primer lanzamiento MVP

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

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

1.0.0 - Listo para producción

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

🏢 Empresa / Regulada

2.1.0 → Lanzamiento cuatrimestral

2.1.1+sec.patch.cve2024 → Parche de seguridad con seguimiento

2.2.0-rc.1+audit.ready → Candidato a la revisión previa

Semver estricto 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 alta velocidad

1.2.0 → Producción actual

1.2.1-hotfix.payment → Corrección crítica de errores

1.2.1+urgent.20240315.1430 → Lanzado con marca de tiempo

Pre-establecimiento para pruebas, metadatos para seguimiento de despliegue

🌍 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

La misma versión, metadatos específicos de plataforma

🔄 Integración de CI/CD

1.4.0-alpha.1+build.123 → Pre-establecimiento automatizado

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 despliegue

💡 Consejos Pro:

Utilice metadatos de compilación (+) para el seguimiento, fechas y hora, o información cosmética que no afecta la compatibilidad
Utilice identificadores de versión prelanzamiento (-) para canales de desarrollo que necesitan una prioridad de actualización diferente
Combine ambos para la máxima flexibilidad: 1.2.0-beta.1+ui.dark.theme.20240315
Recuerde: Capgo respeta las reglas de precedencia de semver, por lo que planifique su 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 SemVer oficial. 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. Consulte nuestro informe de problema y Intento de solución Eso nunca se fusionó.

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 ✗ Hay demasiados partes de versión

1.0.0- ✗ Pre-lanzamiento vacío

1.0.0+ ✗ Metadatos de construcción vacío

Capgo Comportamiento de actualización

✓ 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 no como la implementación de __CAPGO_KEEP_0__ unlike npm's implementation.