Esquema de versionado

Aprende cómo Lerian aborda el versionado semántico, gestiona los breaking changes e interpreta las designaciones de release candidate en pre-releases.

El esquema de versionado describe cómo asignamos e incrementamos los números de versión. Aclara el significado de los lanzamientos major, minor y patch, cómo manejamos los breaking changes y el papel de las etiquetas de pre-release.

Siguiendo esta estructura, puedes anticipar el impacto de cada actualización y planificar las migraciones con confianza.

​

Versionado semántico

---

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

Tipo de versión	Frecuencia de incremento	Características	Ejemplo
X (Versión Major)	Evaluada cada dos ciclos de desarrollo, pero solo se lanza si hay cambios significativos.	Puede introducir breaking changes. Requiere pasos de actualización explícitos.	1.0.0 → 2.0.0
Y (Versión Minor)	Cada ciclo de desarrollo	Mantiene la compatibilidad hacia atrás. Introduce nuevas funcionalidades y capacidades.	1.0.0 → 1.1.0
Z (Versión Patch)	Según sea necesario, fuera del ciclo regular	Para hotfixes, parches de seguridad y actualizaciones críticas. Mantiene la compatibilidad hacia atrás.	1.1.0 → 1.1.1

​

Breaking changes

---

Los breaking changes son parte de la evolución natural de la plataforma. Ocurren cuando una actualización modifica o elimina un comportamiento de forma incompatible con versiones anteriores.

Para mantener este proceso predecible, seguimos reglas estrictas y comunicamos con antelación, permitiendo que tus equipos se preparen con confianza.

• Los breaking changes se introducen solo en una versión major.
• Se anuncian con antelación, siempre con guías de migración claras y ejemplos prácticos.
• Las funcionalidades deprecadas emiten avisos antes de la eliminación, dando a los equipos tiempo para ajustarse sin impacto repentino.
• Buscamos minimizar la disrupción agrupando breaking changes y proporcionando soluciones alternativas siempre que sea posible.

​

Ejemplos

• Sustitución de campo: El campo de texto libre route en los payloads de transacción fue reemplazado por routeId (UUID); route sigue siendo aceptado por compatibilidad, pero ya no participa en la validación.
• Reglas de validación: Las variables de entorno ACCOUNT_TYPE_VALIDATION y TRANSACTION_ROUTE_VALIDATION fueron reemplazadas por la API de Configuración de Ledger, que controla la validación contable por ledger sin necesidad de redespliegue.
• Ciclo de deprecación: El campo scale fue eliminado de los montos de transacción en la v3, cuando el manejo de montos pasó a un sistema numérico.

​

Designaciones de pre-release

---

Usamos las siguientes designaciones de pre-release cuando aplica:

Designación	Descripción	Características	Ejemplo
-alpha.N	Builds iniciales de desarrollo.	Potencialmente inestables, no destinadas a producción. Pueden contener funcionalidades incompletas.	1.1.0-alpha.1
-beta.N	Builds con funcionalidades completas en prueba.	Adecuadas para entornos de prueba. Funcionalidades congeladas, foco en estabilidad y corrección de bugs.	1.1.0-beta.1
-rc.N	Release Candidates.	Se esperan estables y listas para producción. Solo se aplican correcciones críticas antes del release final.	1.1.0-rc.1

​

Ejemplos

Releases posibles

• 1.0.0 → Release estable inicial
• 1.0.1 → Patch con correcciones de bugs
• 1.1.0-alpha.1 → Alpha para la próxima minor
• 1.1.0-beta.1 → Beta para la próxima minor
• 1.1.0-rc.1 → Release candidate
• 1.1.0 → Release minor estable
• 1.2.0 → Próximo release minor
• 2.0.0 → Nueva versión major