> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# 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**.  <br /><br />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**.  <br /><br /> 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**.  <br /><br /> 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. El campo `route` se sigue aceptando por compatibilidad con versiones anteriores, pero ya no impulsa la validación.
* **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**.  <br /><br /> Pueden contener funciones incompletas.                                         | *1.1.0-alpha.1* |
| **-beta.N**  | Compilaciones con funciones completas en fase de prueba. | **Adecuadas para entornos de prueba.** <br /><br /> 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**.  <br /><br /> 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