Control de versiones de software

Siempre estamos hablando de un software que va en su versión 3.5.6 pero no tenemos idea de qué es cada número. Incluso cuando actualizamos el software en nuestra computadora vemos que algunas actualizaciones van de al 0.3.1 a la 0.3.2 y ni siquiera notamos el cambio, hasta nos molesta que tengamos que actualizar para aparentemente nada.

¿Para qué es el control de cambios en el código?

Los métodos y herramientas disponibles para controlar todo lo referente a cambios en el tiempo de un archivo se le conoce como Control de Versiones. Difícilmente se termina un archivo o documento en el primer intento (Para hacerlo tendrían que ser dioses), normalmente encontramos algún bug o algún error ortográfico o cualquier otra cosa que implique un cambio al archivo original.

Cuando se modifica un archivo pueden pasar dos cosas, mantener un historial de cambios o dejarlo sin una memoria de los cambios realizados, siendo esto último un dolor de cabeza cuando arruinamos aún más el archivo.

Imaginen que están escribiendo un libro de 300 páginas y están involucrados unas 5 personas más (entre editores, otros escritores, gente que da ideas, etc.), si no mantuvieran un control de los cambios que van haciendo es muy probable que se encuentren con el pequeño problema de que el libro pierde sentido.

O más aplicado a un desarrollo, imaginen que están haciendo un sistema en el que están involucradas muchas personas, cada uno trabajando en áreas diferentes, pero que de alguna u otra manera se relacionan entre sí. El sistema al final perdería contexto y no sabrían que significan las líneas de código que ustedes no pusieron.

La buena noticia es que para casos como este ya hay software que se encargan de mantener un control de versiones de manera automática, haciendo la vida más sencilla de todos los involucrados en el proyecto. Entre estos sistemas está el reconocido Subversión, aunque también hay otros como CVS y Git.

Control de versiones con el método X.Y.Z

El método más común para numerar las versiones de un sistema es basándose en dos o tres cifras decimales, dependiendo de la importancia de los cambios es el número que se debe cambiar. La primer cifra siempre se cambia cuando se hizo una modificación crítica o muy importante, siendo la segunda cifra de menor importancia.

Se debe iniciar desde 0.Y.Z, con esto estamos diciendo que el documento no está listo aún o que no cumple con los requerimientos mínimos.
Cada cambio en esta cifra denota una reescritura o la incompatibilidad con versiones anteriores.

La segunda cifra X.0.Z se cambia cuando hay modificaciones en el contenido o la funcionalidad del documento, pero no lo suficientemente importantes como para decir que ya no es el mismo documento.
Cuando se hace un cambio mayor (en la primer cifra), el segundo número se reinicia a 0

La tercer cifra se cambia cuando se hacen correcciones al documento pero no se ha añadido ni eliminado nada relevante.
Si se hace un cambio en la segunda cifra se debe reiniciar el número de la tercera a 0

Los que usan Linux me pueden decir que el núcleo del OS maneja cuatro cifras en lugar de tres y que yo estoy hablando nada más de tres niveles. Pero se pueden tener tantos niveles como sea necesario, aunque tampoco es para que abusen de los números.

¿Versiones Beta, Alpha, RC?

Usar esas dos letras griegas es muy común para mantener versiones, pero no significa que debamos abusar tampoco de ellas y librarnos de los problemas definiendo por años un sistema como Beta (Gmail por ejemplo).

Son versiones especiales, se usan previo a un cambio de versión significativa. Por ejemplo, si tenemos un sistema en la versión 1.9.0, pero queremos hacer cambios para probarlos antes de soltar al siguiente versión mayor, podemos poner el sistema como 2.0a (2.0 alpha) siendo la primer versión previa.

No significa que sea ya una versión completa, nada más es una previa, tomen eso mucho en cuenta siempre. Después de pruebas y modificaciones podemos pasar a la versión 2.0b (2.0 Beta), y se siguen haciendo pruebas y correcciones.

¿Recuerdan Win7 RC? Ese RC o Release Candidate se usa para no utilizar todas las letras griegas en nuestras versiones. Cuando ya tenemos una versión más completa, ya casi terminada y que no puede ser considerada como Beta (porque además ya todos odiamos lo que sea Beta), se usa RC.

Siguiendo con el ejemplo del 2.0, se pondría como 2.0-RC1 (2.0 Release Candidate 1). El 1 es la numeración de la cantidad de RC que son necesarios sacar.

La recomendación más grande es que de cada versión tengan una copia guarda, con los comentarios de los cambios que se hicieron en esta nueva versión. Así podrán consultar lo que han hecho hasta el momento, y de ser necesario poder regresar entre versiones. No modifiquen archivos sin tener una copia de la versión anterior, o lo van a lamentar.

Si usan control de versiones, háganlo con consciencia, no nada más por ver que realmente están trabajando.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.