Actualizaciones y Versiones

Cómo Funcionan las Actualizaciones

Una vez que tu plugin está aprobado y activo, las actualizaciones pasan por un proceso controlado que protege a los comerciantes de cambios inesperados.

Flujo de actualización para plugins aprobados:

1. Edita tu plugin en el Portal de Desarrolladores (nombre, descripción, URL, scopes, etc.)
2. Los cambios se guardan en pending_changes — la versión activa no se toca
3. Envía para re-revisión
4. Si se aprueba: los cambios pendientes se fusionan con la versión activa de forma atómica
5. Si se rechaza: los cambios pendientes se descartan, la versión activa permanece igual

Esto garantiza que los comerciantes siempre vean la última versión aprobada de tu plugin hasta que una actualización sea explícitamente aprobada por el equipo de revisión.

Números de Versión

Usa versionado semántico: MAYOR.MENOR.PARCHE

1.0.0       Lanzamiento inicial
1.0.1       Parche — corrección de error
1.1.0       Menor — nueva característica, compatible con versiones anteriores
2.0.0       Mayor — cambio que rompe compatibilidad
1.0.0-beta.1  Etiqueta de pre-lanzamiento permitida

Reglas:

• Las versiones solo pueden aumentar — las versiones anteriores están bloqueadas
• La versión se lee de package.json por defecto
• Puedes sobrescribir con --set-version en el comando deploy

Publicar una Actualización

# Deploy estándar (solicita confirmación)
whatalo deploy --message "v1.2.0: Sincronización de inventario agregada"

# No interactivo (CI/CD — --force es requerido)
whatalo deploy --force --message "v1.2.0: Sincronización de inventario agregada"

# Sobrescribir versión en lugar de leer desde package.json
whatalo deploy --set-version 1.2.0 --force

El flag --force es requerido en entornos no interactivos (pipelines de CI/CD). Sin él, el comando se pausará esperando input del terminal, lo que colgará o fallará en CI.

Cambios de Scope y Consentimiento del Comerciante

Cuando agregas nuevos permisos a un plugin actualizado, la plataforma aplica un proceso de seguridad de 3 capas:

Capa 1 — Revisión

El equipo de revisión ve un diff de los scopes agregados y eliminados. La expansión de scopes (agregar nuevos permisos) es una escalada de privilegios y recibe mayor escrutinio.

Capa 2 — Propagación

Al aprobarse, los nuevos scopes se agregan a pending_scopes en todas las instalaciones existentes de comerciantes. La instalación actual sigue funcionando con el conjunto anterior de scopes.

Capa 3 — Consentimiento

Cada comerciante ve una pantalla de consentimiento la próxima vez que abre tu plugin. Debe aprobar explícitamente los nuevos permisos antes de que el scope expandido entre en vigor.

Eliminar scopes toma efecto inmediatamente al aprobarse — no se requiere consentimiento del comerciante cuando renuncias a acceso.

Deploy desde CI/CD

Un flujo de lanzamiento típico:

# En tu pipeline de CI después de que los tests pasen:
npm version minor  # o patch / major
whatalo deploy --force --message "Lanzamiento automatizado desde CI"

O con control de versión explícito:

whatalo deploy --set-version 1.3.0 --force --message "Lanzamiento v1.3.0"

Verificar tu Versión Publicada

El comando deploy muestra la versión actual y anterior al completarse:

Plugin   mi-plugin-analiticas
Version  1.3.0
Previous 1.2.1
Status   pending_review

El status refleja el estado de revisión actual de la versión enviada.