> ## 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**.

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 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.