Saltar al contenido

Cambios de Versiones

Esta documentación explica cómo manejar cambios importantes en tu aplicación utilizando canales versionados. Esta aproximación permite mantener diferentes versiones de tu aplicación mientras se garantiza que los usuarios reciben actualizaciones compatibles.

Digamos que tienes:

  • Versión de la aplicación 1.2.3 (versión antigua) - utiliza el canal de producción
  • Versión de la aplicación 2.0.0 (nueva versión con cambios importantes) - utiliza el canal v2
  • Actualización en vivo 1.2.4 (compatible con 1.2.3)
  • Actualización en vivo 2.0.1 (compatible con 2.0.0)

Estrategia: Utilizar siempre el canal predeterminado para versiones principales

Sección titulada “Estrategia: Utilizar siempre el canal predeterminado para versiones principales”

Enfoque recomendado: Establecer un defaultChannel para cada versión principal. De esta manera, siempre puede enviar actualizaciones a grupos de usuarios específicos sin depender de la asignación dinámica de canales.

// Version 1.x releases
defaultChannel: 'v1'
// Version 2.x releases
defaultChannel: 'v2'
// Version 3.x releases (future)
defaultChannel: 'v3'

Sección titulada “1. Crear canal para nueva versión”

Ventana de terminal
Copiar a portapapeles
# Create channel for version 2.x
npx @capgo/cli channel create v2

Sección titulada “2. Actualizar Capacitor Config para la versión 2.0.0”

No necesidad de cambiar de canal dinámico en tu aplicación Capacitor

Actualice su configuración Capacitor antes de compilar la versión 2.0.0 para la tienda de aplicaciones:

capacitor.config.ts
import { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.app',
appName: 'Example App',
plugins: {
CapacitorUpdater: {
// ... other options
defaultChannel: 'v2' // All 2.0.0 users will use v2 channel
}
}
};
export default config;

Sección titulada “3. Administre ramas separadas de Code”

Section titled “3. Manage Separate Code Branches”

Cree ramas de Git separadas para mantener la compatibilidad entre versiones de la aplicación:

ventana de terminal
# Create and maintain a branch for version 1.x updates
git checkout -b v1-maintenance
git push origin v1-maintenance
# Your main branch continues with version 2.x development
git checkout main

Crítico: Nunca envíe paquetes de JavaScript a aplicaciones más antiguas que esperan APIs nativas code/ que no tienen. Siempre construya actualizaciones desde la rama adecuada:

  • rama de mantenimiento v1: Para actualizaciones de aplicaciones 1.x (canales de producción)
  • : Para actualizaciones de aplicaciones 2.x (canales v2)4. Subir paquetes a los canales respectivos

Sección titulada “4. Subir paquetes a los canales respectivos”

ventana de terminal
4. Subir paquetes a los canales respectivos
# For 1.x updates: Build from v1-maintenance branch
git checkout v1-maintenance
# Make your 1.x compatible changes here
npx @capgo/cli bundle upload --channel production
# For 2.x updates: Build from main branch
git checkout main
# Make your 2.x changes here
npx @capgo/cli bundle upload --channel v2
Ventana de terminal
# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

Construye y despliega la versión 2.0.0 a la tienda de aplicaciones. Todos los usuarios que descarguen esta versión (ya sean nuevos usuarios o usuarios existentes que actualizan) utilizarán automáticamente el canal v2 porque está configurado en el paquete de la aplicación.

Cuando lanzes la versión 3.0.0 con más cambios de ruptura:

ventana de terminal
# Create channel for version 3.x
npx @capgo/cli channel create v3
// capacitor.config.ts for version 3.0.0
const config: CapacitorConfig = {
// ...
plugins: {
CapacitorUpdater: {
defaultChannel: 'v3' // Version 3.x users
}
}
};

Ahora puedes enviar actualizaciones a cualquier versión:

  • production canal → Usuarios de la versión 1.x
  • v2 canal → Usuarios de la versión 2.x
  • v3 canal → Usuarios de la versión 3.x

Una vez que todos los usuarios hayan migrado a la versión 2.x (contar 3-4 meses):

  1. Eliminar defaultChannel de su Capacitor configuración
  2. Eliminar el canal v2:
Ventana de terminal
npx @capgo/cli channel delete v2
  1. Eliminar la rama de mantenimiento v1:
Ventana de terminal
git branch -d v1-maintenance
git push origin --delete v1-maintenance

Siempre pruebe las actualizaciones exhaustivamente en cada canal antes de la implementación

Para enviar actualizaciones compatibles con la versión 1.x:

  1. Cambie a la rama de mantenimiento v1:
Ventana de terminal
git checkout v1-maintenance
  1. Haga sus cambios y comitela:
Ventana de terminal
# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance
  1. Construir y subir a la canal de producción:
Ventana de terminal
npx @capgo/cli bundle upload --channel production