Cambios de Ruptura

Escenario de ejemplo

Configuración con IA

Supongamos 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 disruptivos) - 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: Siempre Utiliza defaultChannel para versiones principales

Enfoque recomendado: Establecer un defaultChannel para cada versión principal. Esto garantiza que siempre puedas 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'

Consejo

Ventajas de este enfoque:

• Siempre tener control sobre los usuarios que reciben actualizaciones
• No se necesita cambiar el canal dinámico en tu aplicación code
• Separación clara entre diferentes versiones de la aplicación
• Flexibilidad para enviar actualizaciones a cualquier grupo de versión específica

1. Crear Canal para Nueva Versión

# Create channel for version 2.x
npx @capgo/cli channel create v2

2. Actualizar Capacitor Config para Versión 2.0.0

Actualice su Capacitor config 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;

Nota

Para la versión 1.x: Si no configuró defaultChannel inicialmente, los usuarios de la versión 1.x están en el production canal. Para futuras versiones principales, siempre establezca un canal específico como v3, v43. Gestione ramas separadas __CAPGO_KEEP_0__

Sección titulada “3. Gestione ramas separadas Code”

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

Nunca envíe paquetes de JavaScript a aplicaciones más antiguas que esperan APIs nativas __CAPGO_KEEP_0__ que no tienen. Siempre construya actualizaciones desde la rama adecuada: Never push JavaScript bundles to older apps that expect native code/APIs they don’t have. Always build updates from the appropriate branch:

• Para actualizaciones de aplicaciones 1.x (canal de producción)Para actualizaciones a aplicaciones 1.x (canal de producción)
• Rama principal: Para actualizaciones de aplicaciones 2.x (canales v2)

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

5. Habilitar Autoasignación

# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

6. Desplegar en App Store

Construye y despliega la versión 2.0.0 en 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.

Nota

No se necesitan cambios en code! Dado que defaultChannel: 'v2' está empaquetado con la versión de la tienda de aplicaciones, todos los usuarios que descarguen la versión 2.0.0 utilizarán automáticamente el canal correcto.

Escalado a futuras versiones

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

# 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
    }
  }
};

Now puedes empujar 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

7. Limpieza (Después de la Migración)

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

1. Eliminar defaultChannel de tu Capacitor configuración
2. Borrar el canal v2:

npx @capgo/cli channel delete v2

3. Borrar la rama de mantenimiento v1:

git branch -d v1-maintenance
git push origin --delete v1-maintenance

Consejo

Esta aproximación garantiza que los usuarios solo reciban actualizaciones compatibles con su versión de la aplicación

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

Nota

Puede eliminar con seguridad el canal v2 en Capgo incluso si algunos usuarios aún tienen la sobrescritura de canal. Recibirán automáticamente actualizaciones del canal de producción en su lugar.

Mantener Actualizaciones de Versión 1.x

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

1. Cambiar a la rama de mantenimiento v1:

git checkout v1-maintenance

2. Hacer tus cambios y commit:

# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

3. Compilar y subir a canal de producción:

npx @capgo/cli bundle upload --channel production

Consejo

Mantén tu rama de mantenimiento v1 actualizada con correcciones de errores compatibles con la versión 1.x, pero nunca mezcles cambios que rompen la cadena desde main

Sigue adelante desde Cambios que Rinden

Si estás utilizando Cambios que Rinden para planificar la ruta de canales y la implementación de un despliegue en etapas, conecta con Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales Solución de Pruebas Beta para el flujo de trabajo del producto en Solución de Pruebas Beta, y Solución de Alcance de Versión para el flujo de trabajo del producto en Solución de Alcance de Versión.