Versionado semántico
Seguimos un esquema de versionado semántico modificado con el formato X.Y.Z [-designación], donde:
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 librerouteen los payloads de transacción. El camporoutese 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_VALIDATIONyTRANSACTION_ROUTE_VALIDATION. La API controla la validación contable por ledger sin necesidad de un nuevo despliegue. - Ciclo de obsolescencia: eliminamos el campo
scalede 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:
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

