Cambios de versión
Copie un prompt de configuración con los pasos de instalación y la guía de markdown completa para este plugin.
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.
Escenario de ejemplo
Sección titulada “Escenario de ejemplo”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: Siempre Utiliza defaultChannel para Versiones Principales
Sección titulada “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 releasesdefaultChannel: 'v1'
// Version 2.x releasesdefaultChannel: 'v2'
// Version 3.x releases (future)defaultChannel: 'v3'1. Crea canal para nueva versión
Sección titulada “1. Crea canal para nueva versión”# Create channel for version 2.xnpx @capgo/cli channel create v22. Actualiza Capacitor Config para Versión 2.0.0
Sección titulada “2. Actualiza Capacitor Config para Versión 2.0.0”Actualiza tu configuración de Capacitor antes de construir la versión 2.0.0 para la tienda de aplicaciones:
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;Título de la sección: 3. Gestione ramas separadas de Code
Section titled “3. Manage Separate Code Branches”Crea ramas de Git separadas para mantener la compatibilidad entre versiones de la aplicación:
# Create and maintain a branch for version 1.x updatesgit checkout -b v1-maintenancegit push origin v1-maintenance
# Your main branch continues with version 2.x developmentgit checkout mainCrí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 (canal de producción)
- rama principal: Para actualizaciones de aplicaciones 2.x (canal v2)
4. Subir paquetes a los canales respectivos
Sección titulada “4. Subir paquetes a los canales respectivos”# For 1.x updates: Build from v1-maintenance branchgit checkout v1-maintenance# Make your 1.x compatible changes herenpx @capgo/cli bundle upload --channel production
# For 2.x updates: Build from main branchgit checkout main# Make your 2.x changes herenpx @capgo/cli bundle upload --channel v25. Habilitar Autoasignación
Sección titulada “5. Habilitar Autoasignación”# Allow apps to self-assign to v2 channelnpx @capgo/cli channel set v2 --self-assign6. Desplegar a la Tienda de Aplicaciones
Sección titulada “6. Desplegar a la Tienda de Aplicaciones”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 actualicen) utilizarán automáticamente el canal v2 porque está configurado en el paquete de la aplicación.
Escalando a futuras versiones
Sección titulada “Escalando a futuras versiones”Cuando liberes la versión 3.0.0 con más cambios de ruptura:
# Create channel for version 3.xnpx @capgo/cli channel create v3// capacitor.config.ts for version 3.0.0const config: CapacitorConfig = { // ... plugins: { CapacitorUpdater: { defaultChannel: 'v3' // Version 3.x users } }};Ahora puedes enviar actualizaciones a cualquier versión:
productioncanal → Usuarios de la versión 1.xv2canal → Usuarios de la versión 2.xv3canal → Usuarios de la versión 3.x
7. Limpieza (Después de la Migración)
Sección titulada “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):
- Borrar
defaultChannelde tu Capacitor config - Borrar el canal v2:
npx @capgo/cli channel delete v2- Borrar la rama v1-maintenance:
git branch -d v1-maintenancegit push origin --delete v1-maintenanceSiempre prueba las actualizaciones exhaustivamente en cada canal antes de la implementación
Mantener Actualizaciones de la Versión 1.x
Sección titulada “Mantener Actualizaciones de la Versión 1.x”Para enviar actualizaciones compatibles con la versión 1.x:
- Cambiar a la rama de mantenimiento v1:
git checkout v1-maintenance- Haz tus cambios y haz un commit:
# Make 1.x compatible changesgit add .git commit -m "Fix for v1.x"git push origin v1-maintenance- Construye y sube a un canal de producción:
npx @capgo/cli bundle upload --channel productionSigue adelante desde Cambios que Romban
Sección titulada “Sigue adelante desde Cambios que Romban”Si estás utilizando Cambios que Romban para planificar la ruta de canales y el despliegue en etapas, conecta con Canales para el detalle de implementación en Canales, Canales para el detalle de implementación en Canales, Canales para el detalle 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.