> ## 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 Lerian aborda el versionado semántico, cómo gestionamos los breaking changes y cómo interpretar las designaciones de release candidate utilizadas en builds de pre-release.

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**.  <br /><br />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**.  <br /><br /> 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**.  <br /><br /> 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**: En la v2, el campo `chartOfAccounts` fue eliminado y reemplazado por `transactionRoute`, `routeFrom` y `routeTo` para mayor claridad y control.
* **Reglas de validación**: La variable de entorno `ACCOUNT_TYPE_VALIDATION` se introdujo en la v3, requiriendo validación explícita de account type que antes era opcional.
* **Ciclo de deprecación**: El campo `scale` emitió avisos de deprecación en la v2 antes de ser eliminado por completo en la v3.

## 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**.  <br /><br /> Pueden contener funcionalidades incompletas.          | *1.1.0-alpha.1* |
| **-beta.N**  | Builds con funcionalidades completas en prueba. | **Adecuadas para entornos de prueba.** <br /><br /> 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**.  <br /><br /> 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