Capgo Prueba de Semver

Comprueba la compatibilidad de 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 emulador

Deshabilitar descenso automático bajo nativo

Evita descender cuando se ejecuta nativo code

Deshabilitar 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 cuando version_build cuando el dispositivo solicita al servidor de actualizaciones un paquete. En una aplicación Capacitor, ese valor puede provenir de CapacitorUpdater.version dentro de 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 copie ese valor en la configuración o en los metadatos nativos.

La aplicación Capgo sigue utilizando version_name conocer 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 olvida actualizarla antes de una versión nativa.

Versión de la aplicación nativa

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

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

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

Objetivo de paquete

Comparalo 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.

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

Con: las reglas demasiado estrictas pueden bloquear actualizaciones válidas hasta que se ajuste el canal o el metadato 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 La 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 lanzamiento de aplicación nativa en tiendas

Esto impide que Capgo envíe nunca una actualización incompatible a tu code nativo, 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 interfaz de usuario 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"

Fecha de tiempo para el seguimiento de la implementación

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

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

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

1.3.0-beta.1

Canal de pruebas 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 una precedencia más baja - 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 la versión de lanzamiento con metadatos de interfaz de usuario y fecha de timestamp

Uso real del semver y estrategias de equipo

🚀 Inicio de una empresa / 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 diseño

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 versión de auditoría 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 de bug crítica

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 automatizada con metadatos de despliegue

💡 Consejos Pro:

Utilice metadatos de compilación (+) para rastrear, 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 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. 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+ ✗ Metadata de construcción vacía

Capgo Comportamiento de actualización

✓ La estrategia de versión 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 versión 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 completa de semver, 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 en lugar de la implementación de __CAPGO_KEEP_0__ unlike npm's implementation.