Control de versiones

Se llama control de versiones a la gestin de los diversos cambios que se realizan sobre
los elementos de algn producto o una configuracin del mismo. Una versin, revisin o
edicin de un producto, es el estado en el que se encuentra el mismo en un momento
dado de su desarrollo o modificacin.
Aunque un sistema de control de versiones puede realizarse de forma manual, es muy
aconsejable disponer de herramientas que faciliten esta gestin dando lugar a los
llamados sistemas de control de versiones o VCS (del ingls Version Control
System). Estos sistemas facilitan la administracin de las distintas versiones de cada
producto desarrollado, as como las posibles especializaciones realizadas (por ejemplo,
para algn cliente especfico). Ejemplos de este tipo de herramientas son entre otros:
CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, Mercurial,
Perforce, Fossil SCM.
El control de versiones se realiza principalmente en la industria informtica para controlar
las distintas versiones del cdigo fuente dando lugar a los sistemas de control de
cdigo fuente o SCM (siglas del ingls Source Code Management). Sin embargo, los
mismos conceptos son aplicables a otros mbitos como documentos, imgenes, sitios
web, etc.

Git (pronunciado "guit"2 ) es un software de control de versiones diseado por

Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de
versiones de aplicaciones cuando estas tienen un gran nmero de archivos de
cdigo fuente. Al principio, Git se pens como un motor de bajo nivel sobre el cual
otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. 3 Sin
embargo, Git se ha convertido desde entonces en un sistema de control de
versiones con funcionalidad plena. 4 Hay algunos proyectos de mucha relevancia
que ya usan Git, en particular, el grupo de programacin del ncleo Linux.
El mantenimiento del software Git est actualmente (2009) supervisado por Junio
Hamano, quien recibe contribuciones al cdigo de alrededor de 280
programadores.

Mercurial es un sistema de control de versiones multiplataforma, para

desarrolladores de software. Est implementado principalmente haciendo
uso del lenguaje de programacin Python, pero incluye una implementacin
binaria de diff escrita en C. Mercurial fue escrito originalmente para
funcionar sobre GNU/Linux. Ha sido adaptado para Windows, Mac OS X y
la mayora de otros sistemas tipo Unix. Mercurial es, sobre todo, un
programa para la lnea de comandos. Todas las operaciones de Mercurial

se invocan como opciones dadas a su programa motor, hg (cuyo nombre

hace referencia al smbolo qumico del mercurio).
Las principales metas de desarrollo de Mercurial incluyen un gran
rendimiento y escalabilidad; desarrollo completamente distribuido, sin
necesidad de un servidor; gestin robusta de archivos tanto de texto como
binarios; y capacidades avanzadas de ramificacin e integracin, todo ello
manteniendo sencillez conceptual.1 Incluye una interfaz web integrada.
El creador y desarrollador principal de Mercurial es Matt Mackall. El cdigo
fuente se encuentra disponible bajo los trminos de la licencia GNU GPL
versin 2, lo que clasifica a Mercurial como software libre.

Abrir rama ("branch") o ramificar

Un mdulo puede ser branched o bifurcado en un instante de tiempo de forma
que, desde ese momento en adelante se tienen dos copias (ramas) que
evolucionan de forma independiente siguiendo su propia lnea de desarrollo. El
mdulo tiene entonces 2 (o ms) "ramas". La ventaja es que se puede hacer un
"merge" de las modificaciones de ambas ramas, posibilitando la creacin de
"ramas de prueba" que contengan cdigo para evaluacin, si se decide que las
modificaciones realizadas en la "rama de prueba" sean preservadas, se hace un
"merge" con la rama principal. Son motivos habituales para la creacin de ramas la
creacin de nuevas funcionalidades o la correccin de errores.
Integracin o fusin ("merge")
Una integracin o fusin une dos conjuntos de cambios sobre un fichero o un
conjunto de ficheros en una revisin unificada de dicho fichero o ficheros.

Esto puede suceder cuando un usuario, trabajando en esos ficheros,

actualiza su copia local con los cambios realizados, y aadidos al
repositorio, por otros usuarios. Anlogamente, este mismo proceso puede
ocurrir en el repositorio cuando un usuario intenta check-in sus cambios.

Puede suceder despus de que el cdigo haya sido branched, y un

problema anterior al branching sea arreglado en una rama, y se necesite
incorporar dicho arreglo en la otra.

Puede suceder despus de que los ficheros hayan sido branched,

desarrollados de forma independiente por un tiempo, y que entonces se
haya requerido que fueran fundidos de nuevo en un nico trunk unificado.

Versin de software
El versionado de software es el proceso de asignacin de un nombre, cdigo o nmero
nico, a un software para indicar su nivel de desarrollo. Generalmente se asigna dos

nmeros, mayor.menor (en ingls: major.minor), que van incrementando conforme el

desarrollo del software aumente y se requiera la asignacin de un nuevo nombre, cdigo
o nmero nico. Aunque menos habituales, tambin puede indicarse otro nmero ms,
micro, y la fase de desarrollo en que se encuentra el software.
Se aumenta el nmero cuando:

mayor: el software sufre grandes cambios y mejoras.

menor: el software sufre pequeos cambios y/o correcciones de errores.

micro: se aplica una correccin al software, y a su vez sufre pocos cambios.

fase: se indica si se encuentra en una fase de desarrollo que no sea la final o

estable, es decir, una fase inestable o en pruebas. Se suele indicar con un guion
seguido de la fase correspondiente en minsculas, o un espacio seguido de la
fase. Puede haber varias versiones de una misma fase, para indicar el avance en
el desarrollo del software pero manteniendo la fase para indicar que todava es
inestable, indicndose aadiendo un nmero al final del nombre de la fase que va
incrementando conforme se publiquen nuevas versiones de esta fase.
Ejemplo

mayor.menor: 1.2
mayor.menor.micro: 1.2.1
mayor.menor.fase (guion): 1.2-alpha
mayor.menor.fase (espacio): 1.2 Beta
mayor.menor.fase+versin fase (guion): 1.2-rc1
mayor.menor.fase+versin fase (espacio): 1.2 RC1
mayor.menor.micro.fase+versin fase (guion): 1.2.1-beta

Alpha / Alfa
Es la primera versin del programa, la cual es enviada a los verificadores para
probarla.
Algunos equipos de desarrollo utilizan el trmino alfa informalmente para referirse
a una fase donde un producto todava es inestable, aguarda todava a que se
eliminen los errores o a la puesta en prctica completa de toda su funcionalidad,
pero satisface la mayora de los requisitos.
El nombre se deriva de alfa, la primera letra en el alfabeto griego.

Beta
Una versin beta o lanzamiento beta representa generalmente la primera
versin completa del programa informtico o de otro producto, que es posible que
sea inestable pero til para que las de inspeccin previa (preview) o como una
inspeccin previa tcnica (technical preview [TP]). Esta etapa comienza a menudo

cuando los desarrolladores anuncian una congelacin de las caractersticas del

producto, indicando que no sern agregadas ms caractersticas a esta versin y
que solamente se harn pequeas ediciones o se corregirn errores. Las
versiones beta estn en un paso intermedio en el ciclo de desarrollo completo. Los
desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces
el pblico en general) para una prueba de usuario. Los probadores divulgan
cualquier error que encuentran y caractersticas, a veces de menor importancia,
que quisieran ver en la versin final.
Cuando una versin beta llega a estar disponible para el pblico en general, a
menudo es extensamente probada por los tecnolgicamente expertos o
familiarizados con versiones anteriores, como si el producto estuviera acabado.
Generalmente los desarrolladores de las versiones betas del software gratuito o de
cdigo abierto los lanzan al pblico en general, mientras que las versiones beta
propietarias van a un grupo relativamente pequeo de probadores. En febrero de
2005, ZDNet public un artculo acerca del fenmeno reciente de las versiones
beta que permanecan a menudo por aos y que eran utilizada como si estuvieran
en nivel de produccin.1 Observa que Gmail, igual que las noticias de Google, por
ejemplo, estuvieron en beta por un perodo de tiempo muy largo (5 aos). Esta
tcnica puede tambin permitir a un desarrollador retrasar el ofrecimiento de
apoyo total o la responsabilidad de ediciones restantes. Los receptores de betas
altamente propietarias pueden tener que firmar un acuerdo de no revelacin.
Como esta es la segunda etapa en el ciclo de desarrollo que sigue la etapa de
alfa, esta se nombra como la siguiente letra griega beta.

Versin candidata a definitiva (RC)

Una versin candidata a definitiva, candidata a versin final o candidata para
el lanzamiento, aunque ms conocida por su nombre en ingls release
candidate, comprende un producto final, preparado para publicarse como versin
definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto
implementa todas las funciones del diseo y se encuentra libre de cualquier error
que suponga un punto muerto en el desarrollo. Muchas empresas de desarrollo
utilizan frecuentemente este trmino. Otros trminos relacionados incluyen
gamma, delta (y tal vez ms letras griegas) para versiones que estn
prcticamente completas pero todava en pruebas; y omega para versiones que se
creen libres de errores y se hallan en el proceso final de pruebas. Gamma, delta y
omega son, respectivamente, la tercera, cuarta y ltima letras del alfabeto griego.
Considerada muy estable y relativamente libre de errores con una calidad
adecuada para una distribucin amplia y usada por usuarios finales. En versiones
comerciales, puede estar tambin firmada (usado para que los usuarios finales
verifiquen que el cdigo no ha sido cambiado desde su salida). La expresin de

que un producto "sea dorado" significa que el cdigo ha sido completado y que
"est siendo producido masivamente y estar en venta prximamente".

Versin de disponibilidad general (RTM)

La versin de disponibilidad general (tambin llamada "dorada") de un producto es
su versin final. Normalmente es casi idntica a la versin candidata final, con slo
correcciones de ltima hora. Esta versin es considerada muy estable y
relativamente libre de errores con una calidad adecuada para una distribucin
amplia y usada por usuarios finales. En versiones comerciales, puede estar
tambin firmada (usado para que los usuarios finales verifiquen que el cdigo no
ha sido cambiado desde su salida). La expresin de que un producto "sea dorado"
significa que el cdigo ha sido completado y que "est siendo producido
masivamente y estar en venta prximamente".
El trmino "dorado" se refiere anecdticamente al uso del "disco maestro de oro"
que fue frecuentemente usado para enviar la versin final a los fabricantes que lo
usan para producir las copias de venta al detalle. Esto puede ser una herencia de
la produccin musical. En algunos casos, sin embargo, el disco maestro est
realmente hecho de oro, tanto por apariencia esttica como por resistencia a la
corrosin.
Microsoft y otros usan el trmino release to manufacturing (RTM) para referirse a
esta versin (para productos comerciales como Windows 7, como "Build 7600 is
the Windows 7 RTM release"), y release to Web (RTW) para productos libremente
descargables.

Estable/inestable
En la programacin de cdigo abierto los nmeros de las versiones, o los trminos
estable e inestable, normalmente distinguen las fases del desarrollo. En el
pasado, el ncleo Linux usaba el nmero de versin para denotar si una versin
era estable o inestable. En efecto, las versiones estaban formada por cuatro
nmeros, separados por un punto. Una cifra impar en el segundo nmero de la
versin indicaba una versin inestable. Hoy en da ya no se usa esta convencin, y
todas las versiones son estables independientemente del nmero de versin. En la
prctica el uso de nmeros pares e impares para indicar la estabilidad de un
producto ha sido usado por otros muchos proyectos de software libre.
Este concepto tambin se aplica al software empaquetado en
algunas
distribuciones Linux como Debian, de modo que existe una rama o conjunto de
paquetes considerados estables y otra rama considerada inestable. Esta ltima
rama aporta versiones de programas ms recientes que la estable pero que no
estn tan probados.