Capgo Verificador de Semver

Verifique la compatibilidad de la versión semántica para actualizaciones de su aplicación Capacitor

Versión Local

La versión que su aplicación instalada informa a Capgo, desde la configuración o los metadatos nativos de la aplicación.

Versión Remota

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

¿Qué significa "Versión Local"?

La Versión Local es la versión que ya está en el dispositivo cuando solicita a un 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 nativa de la aplicación 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.

Configuración de Capacitor

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

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

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

Versión de la aplicación nativa

Utilice la versión de la plataforma, 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 liberación varían.

Diseño de paquete

Compare it with remote bundle versions, channel semver rules, or upload constraints such as --native-version.

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

Con: 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 versión que el dispositivo informaría como local, y luego compara con la versión de paquete remoto que deseas que Capgo entregue.

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

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 significativos, requiere lanzamiento de la tienda de aplicaciones nativas

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

Estrategias de 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

Timestamp para el seguimiento de la implementación

1.2.0+actualización.de.refresco.modo.oscuridad

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 compilación de CI/CD y commit de 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 versión preliminar (-) - Canales de desarrollo

1.3.0-beta.1

Canales de prueba de beta

1.3.0-hotfix.pago

Rama de reparación urgente

1.3.0-feature.newapi

Prueba de rama de características

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

Enfoque híbrido - 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

Casos de uso semántico del mundo real y estrategias de equipo

🚀 Desarrollo rápido / Inicio de una empresa

0.1.0 - Primer lanzamiento MVP

0.2.0-beta.1 - Prueba de nueva característica

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 el desarrollo pre-1.0, metadatos para el seguimiento de diseño

🏢 Empresa / Regulada

2.1.0 → Lanzamiento trimestral

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 a la auditoría

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 de contenido

⚡ Estrategia de parche rápido

1.2.0 → Producción actual

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 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 aplicaciones progresivas

Misma versión, metadatos específicos de plataforma

🔄 Integración de CI/CD

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

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 construcción (+) para rastrear, fechas y hora, o información cosmética que no afecta la compatibilidad
Utilice identificadores de prelanzamiento (-) 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 versionamiento semántico estricto

Diferente a la implementación de semver de npm, Capgo sigue estrictamente la especificación de SemVer oficial. 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 de manera diferente a lo que requiere la especificación. Consulte nuestro 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' al principio

1.0 ✗ Falta la versión de parche

1.0.0.0 ✗ Hay demasiados partes de versión

1.0.0- ✗ La versión pre-estable no está vacía

1.0.0+ ✗ La información de build no está vacía

Capgo Comportamiento de actualización

✓ Las actualizaciones de parche se aplican automáticamente (1.0.0 → 1.0.1)

✓ Las actualizaciones menores requieren la configuración del canal (1.0.0 → 1.1.0)

✗ Las actualizaciones mayores requieren la publicación de la aplicación nativa en la tienda (1.0.0 → 2.0.0)

⚠ Las versiones pre-estable requieren una configuración explícita

Esta herramienta sigue la especificación de Semantic Versioning a diferencia de la implementación de npm.