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: En la v2, el campo
chartOfAccountsfue eliminado y reemplazado portransactionRoute,routeFromyrouteTopara mayor claridad y control. - Reglas de validación: La variable de entorno
ACCOUNT_TYPE_VALIDATIONse introdujo en la v3, requiriendo validación explícita de account type que antes era opcional. - Ciclo de deprecación: El campo
scaleemitió 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. 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