Esquema de versionado

Aprende cómo aplica Lerian el versionado semántico, cómo manejamos los cambios incompatibles y cómo interpretar las designaciones de release candidate usadas en compilaciones previas al lanzamiento.

El esquema de versionado describe cómo asignamos e incrementamos los números de versión. Aclara el significado de los lanzamientos mayores, menores y de parche, cómo manejamos los cambios incompatibles y el rol de las etiquetas de prelanzamiento.

​

Versionado semántico

---

Seguimos un esquema de versionado semántico modificado con el formato X.Y.Z [-designación], donde:

Tipo de versión	Frecuencia de incremento	Características	Ejemplo
X (versión mayor)	Se evalúa cada dos ciclos de desarrollo, pero solo se publica si hay cambios significativos.	Puede introducir cambios incompatibles. Requiere pasos de actualización explícitos.	1.0.0 → 2.0.0
Y (versión menor)	Cada ciclo de desarrollo	Mantiene compatibilidad con versiones anteriores. Introduce nuevas funciones y funcionalidades.	1.0.0 → 1.1.0
Z (versión de parche)	Según sea necesario, fuera del ciclo regular	Para hotfixes, parches de seguridad y actualizaciones críticas. Mantiene compatibilidad con versiones anteriores.	1.1.0 → 1.1.1

​

Cambios incompatibles

---

Un cambio incompatible ocurre cuando una actualización modifica o elimina un comportamiento de forma que no es totalmente compatible con versiones anteriores.

Para mantener este proceso predecible, seguimos reglas estrictas y comunicamos con anticipación.

• Introducimos cambios incompatibles solo en una versión mayor.
• Se anuncian con anticipación, siempre con guías de migración y ejemplos.
• Las funciones obsoletas emiten advertencias antes de eliminarse, para que los equipos tengan tiempo de adaptarse.
• Buscamos minimizar la disrupción agrupando los cambios incompatibles y ofreciendo soluciones alternativas siempre que sea posible.

​

Ejemplos

• Reemplazo de campo: routeId (UUID) reemplazó al campo de texto libre route en los payloads de transacción. v1 todavía acepta route cuando routeId no está presente. v2 solo acepta routeId.
• Reglas de validación: la API de Ledger Settings reemplazó las variables de entorno ACCOUNT_TYPE_VALIDATION y TRANSACTION_ROUTE_VALIDATION. La API controla la validación contable por ledger sin necesidad de un nuevo despliegue.
• Ciclo de obsolescencia: eliminamos el campo scale de los montos de transacción en v3, cuando el manejo de montos pasó a un sistema numérico.

​

Designaciones de prelanzamiento

---

Usamos las siguientes designaciones de prelanzamiento cuando corresponde:

Designación	Descripción	Características	Ejemplo
-alpha.N	Compilaciones de desarrollo temprano.	Potencialmente inestables, no aptas para producción. Pueden contener funciones incompletas.	1.1.0-alpha.1
-beta.N	Compilaciones con funciones completas en fase de prueba.	Adecuadas para entornos de prueba. Con funciones congeladas, enfocadas en estabilidad y corrección de errores.	1.1.0-beta.1
-rc.N	Candidatas a lanzamiento.	Se espera que sean estables y listas para producción. Solo se aplican correcciones de errores críticos antes del lanzamiento final.	1.1.0-rc.1

​

Ejemplos

Lanzamientos potenciales

• 1.0.0 → Lanzamiento estable inicial
• 1.0.1 → Parche con corrección de errores
• 1.1.0-alpha.1 → Alfa para la próxima versión menor
• 1.1.0-beta.1 → Beta para la próxima versión menor
• 1.1.0-rc.1 → Candidata a lanzamiento
• 1.1.0 → Versión menor estable
• 1.2.0 → Próxima versión menor
• 2.0.0 → Nueva versión mayor