Al lanzar una versión mayor
Gestionar el versionado puede ser difícil; normalmente quieres enviar una actualización Major cuando hay cambios importantes para los usuarios.
Pero el versionado no es para eso: la versión de la App Store es distinta a la versión Native.
La versión Native sirve para gestionar breaking changes en el code
En iOS, por ejemplo, iOS 16 es la store version de Apple, pero la versión code es 20A5283p (parece que ahí no usan SemVer)
¡Ahora queda claro que no las mezclamos y las usamos para lo que fueron creadas!
Lanzamiento de versión mayor
En tu app de Capacitor, se necesita un major release cuando hay un breaking change. Por ejemplo, un nuevo target de iOS (15 a 16), una nueva versión de Capacitor (3 a 4), o un plugin (1.2 a 2.0) que uses se ha actualizado a una versión mayor.
Este cambio significa que todas las herramientas deben alinearse para gestionar el breaking change.
Por eso Capgo sigue este sistema.
Si lanzas una versión mayor, Capgo no se la enviará a un usuario que no la tenga instalada desde la tienda.
Este comportamiento se puede personalizar. Puedes aprender más al respecto aquí
Versiones
Dónde Capgo encuentra la versión para comparar
iOS
Lo usará Capgo para comparar con la versión de JavaScript y detectar la actualización Major
En iOS, la variable se define 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 configuró en tu Info.plist archivo.
Puedes sobrescribir este comportamiento configurando la clave version en
capacitor.config.jsonarchivo docs aquí
Android
Capgo lo usará para comparar con la versión de JavaScript y detectar una actualización major
en Android, la variable se define en tu proyecto aquí android/app/build.gradle bajo la clave defaultConfig.versionName
Puedes sobrescribir este comportamiento configurando la clave version en
capacitor.config.jsonarchivo docs aquí
JavaScript
Capgo lo usará para comparar con la versión nativa y detectar una actualización major
en JavaScript, la variable se define en tu proyecto aquí package.json bajo la clave version
Ejemplo
Tu app de Ionic tiene actualmente la versión 1.2.3 con Capacitor 3
Estás realizando la actualización a capacitor 4.
Debes actualizar tu número de versión a 2.2.3, así todos tus paquetes incluirán Capgo notificando este gran cambio.
Cuando lances esta versión a Capgo y a la App Store.
Todos los próximos live update en Capgo 2.2.4 nunca se enviarán al usuario con la 1.2.3 versión. Solo con la 2.2.3 versión.
Si sigues este patrón, no tendrás de qué preocuparte, todo está bajo control.
If I don’t follow this
En este caso, significa que tendrás que enviar tu nueva app con Capacitor 4 a Apple y Google, pero no a Capgo.
Luego tendrás que esperar a que el 90% o incluso el 100% de tus usuarios tengan la app; probablemente tardará meses.
Mientras tanto, no podrás enviar ninguna actualización con Capgo, ya que los usuarios antiguos no podrán recibir la nueva versión. No tienes forma de seleccionar solo a algunos usuarios para recibir la actualización.
Continuar con Cómo lanzar una versión mayor en capgo
Si estás usando Cómo lanzar una versión mayor en capgo para planificar rollbacks y control de versiones, conéctalo con Reversiones para los detalles de implementación en Rollbacks, Segmentación por versión para los detalles de implementación en Version Targeting, Comportamiento de actualización por el detalle de implementación en Update Behavior, bundle por el detalle de implementación en el bundle, y Live Updates de Capgo por el flujo de trabajo del producto en Capgo Live Updates.
