Al liberar una versión mayor
La versión puede ser difícil de gestionar, generalmente deseas enviar una actualización mayor cuando aparece un cambio importante para los usuarios.
Pero la versión no está hecha para eso, la versión del tienda de aplicaciones es diferente de la versión nativa.
La versión nativa está diseñada para gestionar cambios que rompen en el code
Por ejemplo, en IOS, iOS 16 es la store version de Apple, pero la versión de code es 20A5283p (no parecen usar SemVer allí)
Ahora está claro que no los mezclamos y los usamos para lo que están hechos!
Lanzamiento mayor
En tu aplicación Capacitor, un lanzamiento mayor es necesario cuando sucede un cambio disruptivo. Por ejemplo, una nueva plataforma IOS (15 a 16), o una nueva versión de Capacitor (3 a 4), o un plugin (1.2 a 2.0) que usas ha sido actualizado a una versión mayor.
Este cambio significa que todas las herramientas deben estar alineadas para manejar el cambio disruptivo.
Eso es por qué Capgo sigue este sistema.
Entonces, si lanzas una versión mayor, Capgo no la enviará a un usuario que no la tenga instalada desde la tienda.
Este comportamiento se puede personalizar. Puedes aprender más sobre ello aquí
Versiones
Donde Capgo encuentra la versión para comparar
IOS
Será utilizado por Capgo para compararlo con la versión de JavaScript y encontrar una actualización mayor
En IOS, la var se establece en tu proyecto aquí ios/App/App/Info.plist bajo la claveCFBundleShortVersionString o ios/App/App.xcodeproj/project.pbxproj bajo la clave MARKETING_VERSION si MARKETING_VERSION se estableció en tu Info.plist archivo.
Puedes sobreescribir este comportamiento estableciendo la clave de versión en
capacitor.config.jsonarchivo documentación aquí
Androide
Será utilizado por Capgo para comparar con la versión de JavaScript y encontrar una actualización mayor
en Android, la variable se establece en tu proyecto aquí android/app/build.gradle bajo la clave defaultConfig.versionName
Puedes sobrescribir este comportamiento estableciendo la clave de versión en
capacitor.config.jsonarchivo documentación aquí
JavaScript
Será utilizado por Capgo para comparar con la versión nativa y encontrar una actualización mayor
en JavaScript, la variable se establece en tu proyecto aquí package.json bajo la clave version
Ejemplo
Tu aplicación de Ionic se está liberando actualmente con la versión 1.2.3 With Capacitor 3
Estás realizando la actualización a capacitor 4.
Debes actualizar el número de versión a 2.2.3, luego todas tus paquetes incluirán Capgo con advertencia de este gran cambio.
Cuando lanzes esta versión a Capgo y la Tienda de Aplicaciones.
Todos los siguientes actualizaciones en vivo en Capgo 2.2.4 no se enviarán a los usuarios con 1.2.3 versión. Solo con 2.2.3 versión.
Si sigues este patrón, no hay nada de qué preocuparse, todo está bien gestionado.
Si no lo hago
En este caso, eso significa que debes enviar tu nueva aplicación con Capacitor 4 a Apple y Google, pero no a Capgo.
Tienes que esperar que el 100% de tus usuarios, tenga la aplicación o al menos el 90%, le tomará meses, probablemente.
Mientras tanto no puedes enviar ninguna actualización con Capgo, ya que los usuarios antiguos no pueden obtener la nueva versión.
Keep going from How to release major version in capgo
Sigue leyendo de Cómo liberar una versión mayor en __CAPGO_KEEP_0__ How to release major version in capgo Cómo liberar una versión mayor en __CAPGO_KEEP_0__ para planificar el rollback y el control de versiones, conecta con Rollbacks para los detalles de implementación en Rollbacks, Version Targeting para los detalles de implementación en Version Targeting, Update Behavior paquete para el detalle de implementación en paquete, y Capgo Actualizaciones en vivo para el flujo de trabajo del producto en Capgo Actualizaciones en vivo.
