Cuando se lanza 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 de la tienda de aplicaciones es diferente de la versión nativa.
La versión nativa está hecha para gestionar cambios rotos en el code
Por ejemplo, en IOS, iOS 16 es la store version de Apple, pero la versión 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, es necesario un lanzamiento mayor cuando ocurre un cambio rotos. Por ejemplo, un nuevo objetivo de 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 rotos.
Eso es por qué Capgo sigue este sistema.
Por lo tanto, si publica una versión mayor, Capgo no la enviará a un usuario que no la tenga instalada desde la tienda.
Este comportamiento se puede personalizar. Puede obtener más información sobre ello aquí
Versiones
¿Dónde Capgo encuentra la versión para comparar
iOS
Se utilizará por Capgo para comparar con la versión de JavaScript y encontrar una actualización mayor
En iOS, la variable se establece en su 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 fue configurado en tu Info.plist archivo.
Puedes sobreescribir este comportamiento estableciendo la clave de versión en
capacitor.config.jsonarchivo documentación aquí
Android
Se utilizará 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 sobreescribir este comportamiento estableciendo la clave de versión en
capacitor.config.jsonarchivo documentación aquí
JavaScript
Se utilizará por Capgo para comparar con la versión nativa y encontrar actualizaciones importantes
en JavaScript, el var 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 con Capacitor 3
Estás realizando la actualización a capacitor 4.
Necesitas actualizar el número de versión a 2.2.3, luego todos tus paquetes incluirán Capgo con notificación de este gran cambio.
Cuando liberes esta versión a Capgo y la Tienda de Aplicaciones.
Todas las siguientes actualizaciones en vivo en Capgo 2.2.4 no se enviará a los usuarios con 1.2.3 versión. Solo con 2.2.3 versión.
Si sigues este patrón, no tienes que preocuparte más, todo está bien gestionado.
Si no sigo este
En este caso, eso significa que tienes que enviar tu nueva aplicación con Capacitor 4 a Apple y Google, pero no a Capgo.
Luego tienes que esperar que el 100% de tus usuarios, tengan la aplicación o al menos el 90%, esto 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. No tienes una forma de seleccionar solo a algunos usuarios para que recibieran la actualización.
Sigue adelante desde Cómo liberar una versión mayor en capgo
Si estás utilizando Cómo liberar una versión mayor en capgo 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 para los detalles de implementación en Update Behavior, bundle para los detalles de implementación en bundle, y Capgo Actualizaciones en Vivo para el flujo de trabajo del producto en Capgo Actualizaciones en Vivo.
