A continuación les ofrezco unos comentarios acerca de un enfoque llamado semantic versioning. Esta guía ha sido formalizada por Tom Preston-Werner (inventor de Gravatar y co-fundador de Github) para lidiar con las dependencias de las aplicaciones de software. Muchas veces leí en las conversaciones de la lista bloodhound-dev@incubator.apache.org que los números de las versiones son ''baratos''. Para un proyecto que está en su fase inicial este consejo creo que es válido. Sin embargo, en mi opinión se deben considerar otras variantes para desarrollos con mayor madurez que implican un número considerable de usuarios. De gran importancia es este tema para librerías que son utilizadas muy frecuentemente para desarrollar distintos tipos de software.
¿Qué es el versionado semántico?
La versión 2.0.0 define este sistema de numeración de versiones de la siguiente manera:
- Cada versión se identifica utilizando tres números separados por punto MAJOR.MINOR.PATCH
e.g. 2.3.1
- Los números de las versiones sucesivas se incrementan considerando las siguientes
reglas generales
- Se incrementa MAJOR cuando se realizan cambios incompatibles en la API,
- Se incrementa MINOR cuando se añaden nuevos elementos compatibles con versiones anteriores,
- Se incrementa PATCH cuando se corrigen errores y el resultado es compatible con versiones anteriores.
- Se incrementa MAJOR cuando se realizan cambios incompatibles en la API,
- Se permiten ciertos calificadores para distribuciones todavía en desarrollo
(e.g. alpha, beta, release candidate, ...)
¿Para qué sirve?
El objetivo fundamental consiste en prevenir, o al menos tener la capacidad de detectar casos del fenómeno conocido como dependency hell. En el ámbito de la ingeniería de software es muy importante poder hacer algo al respecto mientras se desarrollan sistemas complejos con gran número de dependencias. Bajo este esquema los números de versiones y la manera en que se asignan ofrecen rápidamente una información valiosa acerca del código y la compatibilidad de las mejoras incorporadas de una versión a la siguiente.
Ejemplo : La aplicación A se construye utilizando la versión 2.3.6 de la librería L.
Los usuarios finales la instalan de forma automática desde un repositorio que maneja las
relaciones entre los diferentes paquetes de software disponibles, quizás compilándolos en
tiempo de instalación. Como la librería L respeta los términos del versionado semántico
y la compatibilidad entre las versiones de la rama 2.x.x entonces los autores de la aplicación A
pueden especificar las restricciones L>=2.3.6 , L<3.0.0. En este rango de versiones
los autores de la librería L crean la expectativa de mantener compatibilidad en la API con las consecuentes garantías para permitir el correcto funcionamiento de A.
Consejos prácticos
En mi experiencia como programador y arquitecto de sistemas considero útiles los puntos siguientes:
- Punto 5: La versión 1.0.0 define la primera API pública estable.
- Puntos 9, 10, 11: El estándar no impone un significado especial para las versiones de prueba.
Existen modelos que le asocian un significado también a estas distribuciones intermedias, por ejemplo
el esquema de versiones de Apache™ Subversion.
- Se recomienda que la caducidad de una parte de la API se debe ofrecer inicialmente en una versión
que incremente el número MINOR para que las dependencias puedan prepararse para adoptar versión
subsecuente que incremente el número MAJOR.
Conclusiones
Existen otros esquemas para numerar las versiones. Apache™ Bloodhound no adoptó el versionado semántico. En este caso se consideró el número MAJOR como una señal. Es por eso que la próxima versión será la 0.6.0 a pesar de que es substancialmente diferente a (y en momentos incompatible con) las versiones precedentes; en especial definiendo la API pública de la solución multi-productos.
Sin embargo recomiendo mucho el uso del versionado semántico, el cual empleo en otros proyectos. Para estar al tanto de su utilidad es posible suscribirse mediante RSS.
No hay comentarios:
Publicar un comentario