Saltar al contenido principal

Capgo Prueba de Semver

Comprobar compatibilidad de la política del canal contra la base nativa enviada como versión_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 de paquete asignada al canal resuelto.

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

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

Versión de Aplicación Nativa Base es la versión de aplicación nativa enviada a Capgo 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 capacitor.config.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. Do not assume it is your package.json versión a menos que tu build copie ese valor en la configuración o metadatos nativos.

Capgo todavía utiliza version_name para saber qué paquete descargado está instalado actualmente. Las políticas de semver del canal, como major, minor, y patch comparan 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 desactualizada 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.

Ventaja: coincide con la versión binaria 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 se desvían.

Objetivo de paquete

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

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

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

Para este tester, ingrese la base nativa que el dispositivo envía como version_buildluego compárela con la versión de paquete remoto que desea 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 sus Capacitor aplicaciones.

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

  • Actualizaciones de parche (1.0.0 → 1.0.1): Arreglos de bugs, seguro de aplicar automáticamente
  • Actualizaciones menores (1.0.0 → 1.1.0): New features, backward compatible
  • Actualizaciones importantes (1.0.0 → 2.0.0): Breaking changes, require native app store release

Esto impide que Capgo envíe nunca una actualización incompatible a su aplicación nativa code, protegiendo a sus usuarios de errores y asegurando que su 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 marcaje para seguimiento de despliegue
1.2.0+ui.refresh.oscuridad.de.modo
UI update description for design team
1.2.0+build.4729.commit.a1b2c3d
Número de compilación de CI/CD y commit de Git

Importante: La información de build 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 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
Pruebas de rama de características

Nota: Las versiones de prelanzamiento tienen una menor prioridad - 1.3.0-beta.1 < 1.3.0

🎯 Enfoque híbrido - Lo mejor de ambos mundos

1.3.0-rc.1+ui.redesign.20240315
Release candidate with UI metadata and timestamp

Uso de Semver en el Mundo Real & Estrategias de Equipo

🚀 Desarrollo rápido / Inicio de una empresa

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

Usar 0.x.x para el desarrollo previo a la versión 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 de lanzamiento previo a la auditoría

Semver estricto con metadatos de cumplimiento

🎮 Juegos / Aplicaciones 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 caliente

1.2.0 → Versión actual de producción
1.2.1-hotfix.payment → Corrección crítica de errores
1.2.1+urgent.20240315.1430 → Publicado con fecha de timestamp

Pre-lanzamiento 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-lanzamiento 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 prácticos:
  • Utilice metadatos de construcción (+) para rastrear, fechas y hora, o información cosmética que no afecta la compatibilidad
  • Utilice identificadores de versión preliminar (-) 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, así que planifique su estrategia de canal en consecuencia

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

A diferencia de 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 diferente a lo que requiere la especificación. Consulte nuestra issue reportado 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 ✗ No se permite el 'v' inicial
1.0 ✗ Falta de versión de parche
1.0.0.0 ✗ Múltiples partes de versión
1.0.0- ✗ Pre-establecimiento vacío
1.0.0+ ✗ Metadatos de construcción vacío

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
✓ 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 descenso utiliza la precedencia de semver completa, por lo que 1.0.0 estable es más nuevo que 1.0.0-beta.2

Siguiendo la versión oficial en lugar de la implementación de __CAPGO_KEEP_0__ a diferencia de la implementación de npm.