HOJA 1 DE 10

REVISIÓN 01

MX NEGOCIOS PROYECTOS INTELIGENTES S.A DE C.V

INVESTIGACIÓN DE VERSIONAMIENTO DE SOFTWARE

ELABORÓ: Joseline Serrano Abarca

FECHA DE ELABORACIÓN: 31 de Enero de 2020

CONTROL DE EMISIÓN
No. de Revisón Elaboró Autorizó
01 Joseline Serrano Abarca Ing. Federico Bravo Rivero
Fecha: 31 de enero de 2020 Fecha: 31 de enero de 2020

PI-APE-ITSJR-01
 HOJA 2 DE 10
REVISIÓN 01

ÍNDICE
INTRODUCCIÓN.....................................................................................................................................2
TIPOS DE VERSIONES...........................................................................................................................3
VERSIONES POR XYZ.......................................................................................................................5
VERSIÓN POR FECHA.......................................................................................................................6
CONCLUSIÓN..........................................................................................................................................7
REFERENCIAS.........................................................................................................................................8

PI-APE-ITSJR-01
 HOJA 3 DE 10
REVISIÓN 01

INTRODUCCIÓN

El versionamiento de software o semantic versioning es la manera de etiquetar el código de software en

el que se esta trabajando de forma que se puedan identificar los cambios realizados, tanto por
complejidad o compatibilidad.
En el presente documento se explican los tipos de versionamientos de software existentes y de igual
manera se muestra la forma en como realizarlo de acuerdo a la versión que se tenga en desarrollo.

PI-APE-ITSJR-01
 HOJA 4 DE 10
REVISIÓN 01

TIPOS DE VERSIONES
Pre-Alfa
Pre-alfa se refiere a todas las actividades realizadas durante el proyecto de software antes de las
pruebas formales. Estas actividades pueden incluir análisis de requisitos, diseño de software, desarrollo
de software y pruebas unitarias. En el desarrollo típico de código abierto, hay varios tipos de versiones
pre-alfa. [IVS]

Alfa
Es la primera versión completa del programa, la cual es enviada a los verificadores para probarla.
Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un
producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica
completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.

Beta
Una beta representa generalmente la primera versión completa de un programa informático o de otro
producto, que es posible que sea inestable pero útil para que sea considerada como una versión
preliminar (preview) o como una preliminar técnica (technical preview [TP]). Esta etapa comienza a
menudo cuando los desarrolladores anuncian una congelación de las características del producto,
indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas
ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de
desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores de betas o beta testers (a
veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que
encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.

Cuando una versión beta llega a estar disponible para el público en general, a menudo es extensamente
probada por los tecnológicamente expertos o familiarizados con versiones anteriores, como si el

PI-APE-ITSJR-01
 HOJA 5 DE 10
REVISIÓN 01

producto estuviera acabado. Generalmente los desarrolladores de las versiones betas del software
gratuito o de código abierto los lanzan al público en general, mientras que las versiones beta
propietarias van a un grupo relativamente pequeño de probadores.

Versión candidata a definitiva (RC)

Una versión candidata a definitiva, candidata a versión final o candidata para el lanzamiento (del inglés
release candidate), comprende un producto preparado para publicarse como versión definitiva a menos
que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del
diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo. Muchas
empresas de desarrollo utilizan frecuentemente este término. Otros términos relacionados incluyen
gamma, delta (y tal vez más letras griegas) para versiones que están prácticamente completas pero
todavía 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
distribución amplia y usada por usuarios finales. En versiones comerciales, puede estar también
firmada (usado para que los usuarios finales verifiquen que el código no ha sido cambiado desde su
salida). La expresión de que un producto sea dorada significa que el código ha sido completado y que
está siendo producido masivamente y estará a la venta próximamente.

Versión de disponibilidad general (RTM)

La versión de disponibilidad general (también llamada dorada) de un producto es su versión final.
Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de última hora. Esta
versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una
distribución amplia y usada por usuarios finales. En versiones comerciales, puede estar también
firmada (usado para que los usuarios finales verifiquen que el código no ha sido cambiado desde su
salida). La expresión de que un producto sea dorado significa que el código ha sido completado y que
está siendo producido masivamente y estará en venta próximamente.

PI-APE-ITSJR-01
 HOJA 6 DE 10
REVISIÓN 01

El término dorado se refiere anecdóticamente al uso del disco maestro de oro que fue frecuentemente
usado para enviar la versión final a los fabricantes que lo usan para producir las copias de venta al
detalle. Esto puede ser una herencia de la producción musical. En algunos casos, sin embargo, el disco
maestro está realmente hecho de oro, tanto por apariencia estética como por resistencia a la corrosión.

Estable/inestable
En la programación de código abierto los números de las versiones, o los términos estable e inestable,
normalmente distinguen las fases del desarrollo. En el pasado, el núcleo Linux usaba el número de
versión para denotar si una versión era estable o inestable. En efecto, las versiones estaban formada por
cuatro números, separados por un punto. Una cifra impar en el segundo número de la versión indicaba
una versión inestable. Hoy en día ya no se usa esta convención, y todas las versiones son estables
independientemente del número de versión. En la práctica el uso de números pares e impares para
indicar la estabilidad de un producto ha sido usado por otros muchos proyectos de software libre.

VERSIONES POR XYZ

Un método bastante habitual de numerar las versiones es utilizando dos o tres cifras decimales para
indicar la importancia de los cambios realizados. El cambio de la primera cifra indica cambios más
importantes que el de la segunda. El criterio más habitual es seguir las siguientes normas:
• La primera cifra (X) indica la versión mayor del documento. Si empieza con un cero significa
que el documento aún no está listo o no cumple con los requerimientos mínimos. Cada cambio
en esta cifra denota una reescritura o la incompatibilidad con versiones mayores anteriores.
[ICV]
Ejemplo: 1.0.0, 3.0.0
• La segunda cifra (Y) indica la versión menor del documento. Denota cambios en el contenido
o en la funcionalidad del documento pero no lo suficientemente importantes como para decir

PI-APE-ITSJR-01
 HOJA 7 DE 10
REVISIÓN 01

que ya no es el mismo. Cuando se estrena una versión mayor se deja la versión menor a cero
pero aún así se incluye de modo que la segunda versión mayor sería la 2.0
Ejemplo: 1.2.0, 3.3.0
• La tercera cifra (Z) indica la segunda versión menor. Indica que el documento se ha corregido
pero que no se ha añadido ni eliminado nada relevante. Cuando se estrena una versión menor, es
decir, cuando la segunda versión menor es igual a cero; suele omitirse.
Ejemplo: 1.2.2, 3.3.4
• Pueden añadirse recursivamente versiones menores, algunos proyectos hacen uso de ellas
cuando los criterios de selección de versiones no corresponden con los definidos en los puntos
anteriores. El núcleo del sistema operativo Linux utiliza una numeración de cuatro cifras.
• Otra práctica común es definir versiones especiales como las versiones alpha, beta o las release
candidate. Estas versiones suelen utilizarse antes de llegar a un hito como una nueva versión
menor.Por ejemplo, antes de llegar a la segunda versión mayor, la versión 2.0, puede publicarse
una primera versión previa alpha numerada como 2.0a o 1.99. La segunda versión previa se
llamaría beta y se numeraría como 2.0b o (por ejemplo) 1.999. Si aún así son necesarias más
versiones previas, en vez de optar por más letras griegas se nu

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

VERSIÓN DE PARCHE

PI-APE-ITSJR-01
 HOJA 8 DE 10
REVISIÓN 01

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

PI-APE-ITSJR-01
 HOJA 9 DE 10
REVISIÓN 01

CONCLUSIÓN
Después de haber realizado la investigación sobre el versionamiento del software, pude aprender los
distintos tipos existentes y a su vez el como aplicarlos de acuerdo al avance que se tenga, ya sea en la
versión de lanzamiento o nuevas actualizaciones.
También aprendí la importancia de tener un control de versiones, ya que así se puede saber cuantas
modificaciones se la hecho al software desde su lanzamiento, de igual manera se puede llevar un
control indicando cuales fueron las modificaciones realizadas y así las personas encargadas del mismo
puedan tener un mejor orden.

PI-APE-ITSJR-01
 HOJA 10 DE 10
REVISIÓN 01

REFERENCIAS

Bibliografía
IVS: José Dimaz Luján, ¿Cómo se deciden las versiones de software? , 2017,
https://ed.team/blog/como-se-deciden-las-versiones-del-software
ICV: Wikipedia, Ciclo de vida del lanzamiento de software, ,
https://es.wikipedia.org/wiki/Ciclo_de_vida_del_lanzamiento_de_software

PI-APE-ITSJR-01