Algo que sucede normalmente en el mundo del desarrollo es que buscamos maneras para mejorar y optimizar el código, los proyectos y aplicaciones. El detalle es que cosas buenas que ya existen al ser simples suelen pasar desapercibidas. Una de ellas es el versionamiento del Software, versionado de software o simplemente, asignar versión de software. Depende del país o región.
Existen muchas formas de asignar una versión al software, cada empresa pueda generar sus reglas y está bien, pero como todo en este mundo se busca generar unas reglas y pautas que sirvan como guía.
Antes de continuar es importante tener en cuenta que existen diferentes propuestas para asignar versiones y cada quien puede seguir las que desee.
Versiones por número.
Algo común es realizar el manejo de versiones mediante 3 números: X.Y.Z y cada uno indica una cosa diferente:
- El primero (X) se le conoce como versión mayor y nos indica la versión principal del software. Ejemplo: 1.0.0, 3.0.0
- El segundo (Y) se le conoce como versión menor y nos indica nuevas funcionalidades. Ejemplo: 1.2.0, 3.3.0
- El tercero (Z) se le conoce como revisión y nos indica que se hizo una revisión del código por algun fallo. Ejemplo: 1.2.2, 3.3.4
Ahora que conocemos el significado de cada número, viene una pregunta importante: ¿cómo sabemos cuando cambiarlos y cuál cambiar?
- Versión mayor o X, cuando agreguemos nuevas funcionalidades importantes, puede ser como un nuevo modulo o característica clave para la funcionalidad.
- Versión menor o Y, cuando hacemos correcciones menores, cuando arreglamos un error y se agregan funcionalidades que no son cruciales para el proyecto.
- Revisión o Z, cada vez que entregamos el proyecto.
Versiones por estabilidad.
Además de tener las versiones por números podemos agregar una clasificación por estabilidad del proyecto.
Las opciones que tenemos para esto son: Alpha, Beta.
Alpha es una versión inestable que es muy probable que tenga muchas opciones que mejorar, pero queremos que sea probada para encontrar errores y poder poner a prueba funcionalidades, en la mayoría de los casos podemos decir que esta casi listo el producto. Ejemplo: 1.0Alpha, 1.0a1,1.0a2.
Beta una versión mas estable que Alpha en la que contamos con el producto en su totalidad, y se desea realizar pruebas de rendimiento, usabilidad y funcionamiento de algunos módulos para ver cómo funciona bajo un ambiente no tan controlado. Aquí aperece el nombre de Beta Tester que escuchamos mucho en el mundo del software. Ejemplo: 2.0Beta, 2.0b, 2.0b1
El siguiente paso es RC (Release Candidate), que es el último toque fino del software antes de salir y después de pasar por Beta. Ejemplo: 3.0-RC o también 3.0-RC1.
Mas cosas que manejar con Versiones.
En el mundo del software sabemos que además de los programas que usamos habitualmente existe software más complejo como los videojuegos y sistemas operativos, en ambos casos se necesita considerar los casos de los parches y las fechas de lanzamientos, ambos elementos que también pueden influir en el control de versiones.
Versión de parche.
En el caso de los parches podemos agregar un dígito para señalar el parche, ya teníamos algo así: X.Y.Z y ahora tendríamos algo así: X.Y.Z.P así que P sería el número del parche:
Ejemplo: 1.2.5.2, 02.03.03.01
Versión por fecha.
En algunos necesitamos saber exactamente la fecha en que se publicó el software, entonces podremos utilizar el manejo de versiones por fecha. Este tiene muchas variaciones, se puede tener diferente orden del año, mes y día.
Ejemplo: 1.2.3.1543 donde 15 es el año 2015, 4 es el mes y 3 el día, como ya mencione anteriormente se podrían tener diferentes acomodos y formatos: 1.2.3.4315 o 1.2.3.201543, 1.2.3.1534
Conclusión:
No existe una regla o estándar oficial para normar las versiones de software, existen diferentes propuestas que podemos aplicar, pero siempre es un buen ejercicio que después de leer este artículo pongas atención a las versiones de librerías, software, sistemas operativos, juegos y parches para que veas como lo están haciendo los gigantes de la industria.
Tengo el honor de escribir un artículo semanal para EDteam así que si tienes alguna sugerencia de tema o comentarios puedes dejarlo aquí mismo o hacérmelo llegar por: