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.

github es un hosting y red social de programadores integrados al sistema de control de versiones git.
¿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.
Me parece un muy buen aporte.
Saludos, Hernán . -
siempre es bueno versionar las aplicaciones con cierta coherencia.
Por Miguel el 15 de Diciembre de 2009
Es extraño que no se siguiera con la nomenclatura de letras romanas, deberían llamarse algo como alpha, beta, psi y omega.
El sitio de Subversion para los interesados http://subversion.tigris.org/
El versionado de software es una especie de estándar aplicado de manera pragmática, que se basa en el formato que mencionas, con algunas excepciones. El caso del kernel Linux como explicas es uno de ellos, donde han pasado, si no me equivoco, por unos 3 esquemas de versiones.
Otro algo popular es agregar la fecha, como lo hace Ubuntu, Passenger y otros aplicativos.
En general, la inclusión de la versión del aplicativo o desarrollo depende de varios factores subjetivos, pero que buscan mostrar cambios entre un entregable y otro. Práctica que, en este mundo cada vez orientado más a la web, deja de tener importancia (aunque no desaparece, se muda a un esquema orientado a fechas).
Ahora bien, personalmente, yo no considero un desarrollo real si es que no está en un sistema manejador de versiones. Así de sencillo. No existe ninguna razón para no usar uno.
Como algunos saben, utilizo GIT como DCVS sobre otras opciones (¿Por qué es mejor?), pero realmente cualquiera es competente (aunque todavía me da miedo recordar como era el manejo de branches con svn), así que no puedo dejar de recomendar que usen alguno.
Y una de las ventajas automáticas en esta temática, es que el changelog se genera en base a los commits. De igual modo, puedes crear un TAG de versión en lugar de manejar un branch específico y almacenarlo en tu CVS (aunque sugeriría utilizar algo off-site, como Github y similares).
Así que.. si no estás usando alguno, ¿qué esperas?
*Me han contado...
Pocas veces se tocan temas como estos y es muy interesante.
Por Manolito_BCN el 15 de Diciembre de 2009
Por Abel RL el 15 de Diciembre de 2009
La verdad que todos deberian de usar una version de sus documentos y aplicaciones, no solo lo usamos en software.
Imaginense un psd, donde varios diseñadores trabajen o un feedback con el cliente, para saber que actualizamos tambien sirve.
Te felicito, esperamos aprender usar SVN.
Saludos
La verdad no es complicado y te hace la vida más fácil cuando lo usas.
Por tomasdev el 18 de Diciembre de 2009
Por SaraMorueta el 19 de Diciembre de 2009
Yo utilizo Subversion desde hace un año, y aunque al principio era un poco reacia, lo cierto es que es magnífico. A veces te salva la vida, sobre todo cuando has eliminado algo que no deberías... siempre puedes volver al pasado
Lo que no comprendo es lo que dices en el texto sobre el método X.Y.Z. ¿ Se supone que esto es un estándar más o menos establecido sobre el modo de comentar los cambios que se realizan para ver el grado de importancia de los mismos y la evolución del trabajo? Gracias!
Por konda el 26 de Diciembre de 2009
yo siempre pensaba que esos numeritos eran por que querian
SaraMorueta-blog :
Es así como lo dices. Es un modo de mostrar los cambios que va sufriendo el proyecto y en que importancia. Por ejemplo, no es lo mismo corregir ortografía a cambiar un parrafo completo. Lo segundo hace que el sentido del documento cambie.
Y se maneja como estandar porque no importa el lenguaje o el idioma, es igualmente usando en todo el mundo.
jpcw :
TortoiseSVN es un cliente para Subversion en Windows. No es el sistema o programa en sí. Nada más te facilita las cosas en cuanto al uso de SVN. Hay uno para Mac pero no recuerdo el nombre, Freddie sabe cuál es.
daz_angie-blog :
jpcw :
TortoiseSVN es un cliente para Subversion en Windows. No es el sistema o programa en sí. Nada más te facilita las cosas en cuanto al uso de SVN. Hay uno para Mac pero no recuerdo el nombre, Freddie sabe cuál es.
Por Rodrigo el 30 de Abril de 2010
como se cual es la ultima version de un programa... por ejemplo, tengo una version X.Y.0.37 y otra version X.Y.0.182
es mas nueva la version 2, por ser mayor 182 que 37, o es mayor la primera, si consideramos los numeros como parte decimal ???
gracias.
Por Zarita el 15 de Mayo de 2010
Muchas gracias!
Por ramona el 30 de Septiembre de 2011
Por Anthony el 05 de Noviembre de 2011
Por Patricia el 01 de Junio de 2012
Saludos
Por Fdo. el 07 de Junio de 2012
a ver si alguien conosco del tema
Saludos.
Por Yoni V. el 08 de Agosto de 2012
Conciso y simple.
Gracias.
Por @e1000iosoy el 10 de Enero de 2013
Por Jonathan el 20 de Febrero de 2016
Por Eder Clemente el 10 de Junio de 2016
El control de versiones es indispensable para todo desarrollo. Por eso te puedo recomendar este artículo de <a href="http://okhosting.com/blog/github-y-bitbucket-software-control-de-versiones/">herramientas para control de inversiones</a>, que se complementa en gran manera con este artículo.
Saludos Cordiales!