PaceVer: especificación de versionado para apps móviles con canal nativo y OTA

Fuentes: PaceVer: A Versioning Spec for Mobile Apps with Native and OTA Channels
Imagen generada por IA con el prompt: Split visual of two delivery paths: a slow gated channel resembling a store shelf on one side and a fast over-the-air stream reaching a mobile device on the other. Teal and orange palette, clean editorial tech style.
Imagen generada con IA

PaceVer es una especificación de versionado pensada para aplicaciones móviles que distribuyen actualizaciones a través de dos canales diferenciados: el canal nativo de binarios, que pasa por las tiendas de apps, y el canal OTA (over-the-air), que llega directamente a dispositivos ya instalados. El sistema emplea un número de versión en tres partes con el formato MARKETING.NATIVE.OTA, en el que cada segmento refleja cómo llega la release al usuario y no la magnitud del cambio.

El número MARKETING es libre y lo gestiona el equipo para señalar rediseños, rebautizaciones, hitos o cualquier evento que considere relevante, sin promesa de compatibilidad. El valor 0 marca la etapa previa al lanzamiento; el primer release estable público suele ser 1.0.0. El número NATIVE se incrementa solo cuando una release exige un binario nuevo distribuido por una tienda o canal equivalente (cambios de código nativo, actualizaciones de SDK, cambios de permisos, nuevas dependencias compiladas): es necesariamente lento, supeditado a la revisión de la tienda. El número OTA se incrementa con cada release enviada por aire sobre un binario ya instalado (JavaScript, estilos, contenido, activos dentro del runtime nativo actual): es rápido y suele llegar a los dispositivos en minutos.

Una regla central de PaceVer es que incrementar NATIVE reinicia OTA a 0, ya que un nuevo binario nativo abre un linaje OTA nuevo. Incrementar MARKETING también reinicia, por defecto, NATIVE y OTA, produciendo un 2.0.0 limpio tras un rediseño, aunque los equipos pueden dejar que los números sigan subiendo para obtener un 2.6.2. PaceVer cubre una brecha que SemVer no aborda: SemVer describe qué cambió en términos de compatibilidad, pero no dice nada sobre cómo llega el cambio al usuario, que en móvil es lo que determina la latencia de revisión, la velocidad de despliegue y la reversión. PaceVer convierte ese dato en la propia versión: pasar de 2.5.0 a 2.5.3 fue un push OTA ya en dispositivos; pasar de 2.5.3 a 2.6.0 es un binario nuevo esperando revisión. La especificación fija además que MARKETING, NATIVE y OTA son números únicos del proyecto, no por plataforma, lo que obliga a compartir el mismo binario nativo entre iOS y Android, y que la versión reportada en tiempo de ejecución se componga con MARKETING y NATIVE del binario instalado más el OTA aplicado. PaceVer no sustituye a SemVer para librerías, paquetes o APIs, que siguen beneficiándose del enfoque basado en contrato.