Capgo Prueba de Semver
Comprueba la compatibilidad de la política del canal contra la base nativa enviada como version_build
La versión nativa enviada a Capgo como version_build, desde la configuración o los metadatos de la aplicación nativa.
La versión del paquete asignada al canal resuelto.
¿Qué significa "Versión de Base Nativa"?
La Versión de Base 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 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 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.
Ventajas: fácil de mantener lo mismo en iOS y Android.
Desventajas: la configuración caducada puede informar la versión incorrecta si se olvida de actualizar 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.
Configuración de paquete
Compararlo 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 del 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 que Capgo entregue.
¿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 la aplicación nativa en la tienda
Esta previene que Capgo nunca envíe una actualización incompatible a tu nativo code, protegiendo a tus usuarios de errores y asegurando que tu aplicación permanezca estable.
Estrategias de Semver Flexibles: Más Allá de la Versión Básica
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
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 prelanzamiento (-) - Canales de desarrollo
Nota: Versiones de prelanzamiento tienen una precedencia menor -
1.3.0-beta.1 < 1.3.0
🎯 Enfoque híbrido - Lo mejor de ambos mundos
Uso real del semver y estrategias de equipo
🚀 Inicio de una empresa / Desarrollo rápido
0.1.0 - Primer lanzamiento MVP0.2.0-beta.1 - Pruebas de nuevas características0.2.0+ui.v2 - Metadatos de diseño de interfaz de usuario1.0.0 - Listo para producciónUtilice 0.x.x para el desarrollo de pre-1.0, metadatos para el seguimiento de diseño
🏢 Empresa / Regulada
2.1.0 → Lanzamiento cuatrimestral2.1.1+sec.patch.cve2024 → Parche de seguridad con seguimiento2.2.0-rc.1+audit.ready → Candidato a lanzamiento previo a la auditoríaSemver estricto con metadatos de cumplimiento
🎮 Aplicaciones de juegos / creativas
1.0.0+season.winter.2024 → Contenido estacional1.1.0+event.halloween → Características impulsadas por eventos1.2.0+assets.hd.remaster → Actualizaciones de activosMetadatos creativos para el seguimiento de contenido
⚡ Estrategia de parche rápido
1.2.0 → Producción actual1.2.1-hotfix.payment → Corrección crítica de errores1.2.1+urgent.20240315.1430 → Lanzado con marca de tiempoPre-establecimiento para pruebas, metadatos para seguimiento de despliegue
🌍 Estrategia de múltiples plataformas
1.3.0+ios.optimized → Optimizaciones específicas de iOS1.3.0+android.material3 → Actualizaciones de diseño para Android1.3.0+web.pwa.ready → Capacidad de PWALa misma versión, metadatos específicos de plataforma
🔄 Integración de CI/CD
1.4.0-alpha.1+build.123 → Pre-establecimiento automatizado1.4.0+deploy.staging.456 → Despliegue de etapa1.4.0+prod.final.789 → Despliegue de producciónVersión automatizada con metadatos de despliegue
- Utilice la información de compilación de metadata (+) 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 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
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.