Pasar al contenido principal

Capgo Prueba de Semver

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

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

La versión del paquete asignada al canal resuelto.

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

¿Qué significa "Versión de referencia nativa"?

La Versión de referencia 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 Inicie sesión en su cuenta de __CAPGO_KEEP_0__ para obtener más información sobre cómo configurar el canal de actualizaciones. Si ese ajuste no está presente, el plugin recae en la versión nativa de la aplicación de iOS o Android. No asuma que es su versión a menos que su compilación copie ese valor en la configuración o los metadatos nativos. __CAPGO_KEEP_0__ todavía utiliza capacitor.config.*para saber qué paquete descargado está instalado actualmente. Las políticas de canal semver como package.json version unless your build copies that value into config or native metadata.

Capgo still uses version_name comparan el paquete remoto contra major, minor__CAPGO_KEEP_0__ configuración patch Establezca version_build.

Capacitor config

Ventaja: CapacitorUpdater.version fácil de mantener el mismo en compilaciones de iOS y Android.

Iniciar sesión en su cuenta de __CAPGO_KEEP_0__ para obtener más información sobre cómo configurar el canal de actualizaciones. Si ese ajuste no está presente, el plugin recae en la versión nativa de la aplicación de iOS o Android. No asuma que es su versión a menos que su compilación copie ese valor en la configuración o los metadatos nativos. __CAPGO_KEEP_0__ todavía utiliza para saber qué paquete descargado está instalado actualmente. Las políticas de canal semver como "mayor que", "menor que" y "igual a" ,

Con: Puede informar la versión incorrecta si se olvida de actualizar antes de una liberación nativa.

Versión de la aplicación nativa

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

Pro: se ajusta a 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 liberación se desvían.

Objetivo de empaquetado

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

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

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

Para este tester, ingresa la base nativa que el dispositivo envía como version_buildy compárala con la versión de paquete remoto 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, compatible con versiones anteriores
  • Actualizaciones importantes (1.0.0 → 2.0.0): Cambios importantes, requieren lanzamiento de la tienda de aplicaciones nativas

Esto impide 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, puedes extenderlo para las necesidades de tu equipo utilizando identificadores de pre-lanzamiento y metadatos de construcción:

🏷️ Metadatos de construcción (+) - La capa "cosmética"

1.2.0+20240315.142530
Timestamp para el seguimiento de la implementación
1.2.0+ui.refresh.dark-mode
Descripción de actualización de interfaz para equipo de diseño
1.2.0+build.4729.commit.a1b2c3d
Número de compilación CI/CD y commit Git

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

🔧 Identificadores de prelanzamiento (-) - Canales de desarrollo

1.3.0-beta.1
Canal de prueba beta
1.3.0-hotfix.payment
Rama de corrección urgente
1.3.0-feature.nuevaapi
Prueba de rama de características

Nota: Las versiones 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 de casos reales de Semver y estrategias de equipo

🚀 Desarrollo rápido / Inicio de una startup

0.1.0 - Primer lanzamiento MVP
0.2.0-beta.1 - Prueba de nuevas características
0.2.0+ui.v2 - Metadatos de rediseño de interfaz de usuario
1.0.0 - Listo para producción

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

🏢 Empresa / Regulada

2.1.0 → Lanzamiento cuatrimestral
2.1.1+sec.patch.cve2024 → Corrección 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 Hotfix

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

Pre-lanzamiento para pruebas, metadatos para seguimiento de despliegue

🌍 Estrategia de Multi-Plataforma

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

Versión igual, metadatos específicos de plataforma

🔄 Integración de CI/CD

1.4.0-alpha.1+build.123 → Pre-lanzamiento automatizado
1.4.0+deploy.staging.456 → Despliegue de etapa
1.4.0+prod.final.789 → Despliegue de producción

Automatización de versionado con metadatos de despliegue

💡 Consejos Pro:
  • Utilice metadatos de construcción (+) para rastrear, fechas y hora, o información cosmética que no afecta la compatibilidad
  • Utilice identificadores de pre-lanzamiento (-) para canales de desarrollo que necesitan diferentes prioridades de actualización
  • 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 versionado semántico estricto

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 comportamiento inesperado.

Por ejemplo, npm trata versiones como 1.0.0-alpha.1 diferentemente que lo requiere la especificación. Consulte nuestra reportado problema y solución intentada que 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 ✗ 'v' de cabeza no permitido
1.0 ✗ Falta de versión de parche
1.0.0.0 ✗ Muy muchas partes de versión
1.0.0- ✗ Vacío pre-establecimiento
1.0.0+ ✗ Vacío metadatos de construcción

Capgo Comportamiento de actualización

Estrategia menor permite cambios de parche en la misma línea mayor.menor, por ejemplo 1.0.0 -> 1.0.1
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.
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 descenso utiliza la precedencia completa de semver, por lo que estable 1.0.0 es más nuevo que 1.0.0-beta.2

Esta herramienta sigue la especificación de Versión semántica oficial a diferencia del npm's implementación.