El control de versiones del software es el proceso de asignar nombres de versión únicos o números de versión únicos a estados únicos del software de computadora. Dentro de una categoría de número de versión determinada (por ejemplo, mayor o menor), estos números generalmente se asignan en orden creciente y corresponden a nuevos desarrollos en el software. En un nivel detallado, el control de revisiones se utiliza para realizar un seguimiento de las versiones incrementales de información, ya sea que esta información sea o no software de computadora, para poder revertir cualquier cambio.
El seguimiento del software informático moderno suele realizarse mediante dos esquemas de control de versiones de software diferentes: un número de versión interna que puede incrementarse muchas veces en un solo día, como un número de control de revisión, y una versión de lanzamiento que normalmente cambia con mucha menos frecuencia, como el control de versiones semántico. [1] o un nombre de código de proyecto.
Los números de expediente se utilizaban especialmente en la administración pública, así como en las empresas, para identificar de forma única expedientes o casos. Para archivos de computadora, esta práctica se introdujo por primera vez con el sistema de archivos ITS del MIT, más tarde el sistema de archivos TENEX para el PDP-10 en 1972. [2]
Posteriormente se agregaron listas de archivos, incluidas sus versiones y dependencias entre ellos. Las distribuciones de Linux como Debian, con su dpkg , crearon desde el principio un software de gestión de paquetes que podía resolver las dependencias entre sus paquetes. El primer intento de Debian fue que un paquete conociera otros paquetes que dependían de él. A partir de 1994 se revirtió esta idea, surgiendo un paquete que conocía los paquetes que necesitaba. Al instalar un paquete, se utilizó la resolución de dependencias para calcular automáticamente los paquetes necesarios e instalarlos con el paquete deseado. Para facilitar las actualizaciones, se introdujeron versiones mínimas de paquetes. Por tanto, el esquema de numeración necesitaba indicar qué versión era más nueva que la requerida. [3] [4] [5]
Se han creado una variedad de esquemas de numeración de versiones para realizar un seguimiento de las diferentes versiones de un software. La ubicuidad de las computadoras también ha llevado a que estos esquemas se utilicen en contextos fuera de la informática.
En los esquemas de control de versiones de software basados en secuencias, a cada versión de software se le asigna un identificador único que consta de una o más secuencias de números o letras. [6] Este es el alcance de los puntos en común; Los esquemas varían ampliamente en áreas como el número de secuencias, la atribución de significado a secuencias individuales y los medios para incrementar las secuencias.
En algunos esquemas, se utilizan identificadores basados en secuencias para transmitir la importancia de los cambios entre versiones. Los cambios se clasifican por nivel de significancia, y la decisión de qué secuencia cambiar entre versiones se basa en la importancia de los cambios de la versión anterior, por lo que la primera secuencia se cambia para los cambios más significativos y los cambios en las secuencias posteriores a la primera representan cambios de importancia decreciente.
Dependiendo del esquema, la importancia puede evaluarse según las líneas de código modificadas, los puntos de función agregados o eliminados, el impacto potencial en los clientes en términos de trabajo requerido para adoptar una nueva versión, el riesgo de errores o cambios importantes no declarados, el grado de cambios en el aspecto visual. diseño, la cantidad de características nuevas o casi cualquier cosa que los desarrolladores de productos o los especialistas en marketing consideren importante, incluido el deseo de marketing de enfatizar la "bondad relativa" de la nueva versión.
El control de versiones semántico (también conocido comoSemVer)[1]es un esquema de versión ampliamente adoptado[7]que codifica una versión mediante un número de versión de tres partes (Major.Minor.Patch), una etiqueta de prelanzamiento opcional y un meta de compilación opcional. etiqueta. En este esquema, el riesgo y la funcionalidad son las medidas de importancia. Los cambios importantes se indican aumentando el número principal (alto riesgo); Las características nuevas e ininterrumpidas aumentan el número menor (riesgo medio); y todos los demás cambios no importantes incrementan el número de parche (riesgo más bajo). La presencia de una etiqueta previa al lanzamiento (-alfa, -beta) indica un riesgo sustancial, al igual que un número importante de cero (0.yz), que se utiliza para indicar un trabajo en progreso que puede contener cualquier nivel de riesgo potencial. cambios importantes (mayor riesgo). Como ejemplo de inferencia de compatibilidad a partir de una versión de SemVer, el software que se basa en la versión 2.1.5 de una API es compatible con la versión 2.2.3, pero no necesariamente con la 3.2.4.
Los desarrolladores pueden optar por saltar varias versiones menores a la vez para indicar que se han agregado características importantes, pero que no son suficientes para justificar el incremento de un número de versión principal; por ejemplo, Internet Explorer 5 de 5.1 a 5.5 o Adobe Photoshop 5 a 5.5. Esto se puede hacer para enfatizar el valor de la actualización para el usuario del software o, como en el caso de Adobe, para representar un lanzamiento a medio camino entre las versiones principales (aunque los niveles de versiones basadas en secuencias no se limitan necesariamente a un solo dígito, como en Blender) . versión 2.91 o Minecraft Java Edition a partir de 1.7.10).
Un enfoque diferente es utilizar los números mayor y menor junto con una cadena alfanumérica que indique el tipo de versión, por ejemplo, "alfa" (a), "beta" (b) o "versión candidata" (rc). Un tren de lanzamiento de software que utilice este enfoque podría verse así: 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (con algunas correcciones), 1.0b3 (con más correcciones) → 1.0rc1 (que, si es lo suficientemente estable ) , 1.0rc2 (si se encuentran más errores) → 1.0. Es una práctica común en este esquema bloquear nuevas funciones y cambios importantes durante las fases de lanzamiento candidato y, para algunos equipos, incluso las versiones beta están bloqueadas solo para corregir errores, para garantizar la convergencia en el lanzamiento de destino.
Otros esquemas imparten significado a secuencias individuales:
Nuevamente, en estos ejemplos, la definición de lo que constituye un cambio "importante" en comparación con un cambio "menor" es completamente subjetiva y depende del autor, al igual que lo que define una "compilación" o en qué se diferencia una "revisión" de una "cambio menor.
Las bibliotecas compartidas en Solaris y Linux pueden usar el formato current.revision.age donde: [8] [9]
Un problema similar de importancia relativa del cambio y nomenclatura de versiones existe en la edición de libros, donde los números o nombres de las ediciones pueden elegirse basándose en distintos criterios.
En la mayoría del software propietario, la primera versión lanzada de un producto de software tiene la versión 1. [ cita necesaria ]
Algunos proyectos utilizan el número de versión principal para indicar versiones incompatibles. Dos ejemplos son Apache Portable Runtime (APR) [10] y FarCry CMS. [11]
A menudo, los programadores escriben software nuevo para que sea compatible con versiones anteriores , es decir, el nuevo software está diseñado para interactuar correctamente con versiones anteriores del software (que utilizan protocolos y formatos de archivo antiguos) y la versión más reciente (que utiliza los protocolos y formatos de archivo más recientes). Por ejemplo, IBM z/OS está diseñado para funcionar correctamente con 3 versiones principales consecutivas del sistema operativo ejecutándose en el mismo sysplex. Esto permite a las personas que ejecutan un clúster de computadoras de alta disponibilidad mantener la mayoría de las computadoras en funcionamiento mientras una máquina a la vez se apaga, se actualiza y se restablece el servicio. [12]
A menudo, los encabezados de los paquetes y el formato de los archivos incluyen un número de versión, a veces el mismo que el número de versión del software que lo escribió; otras veces, un "número de versión de protocolo" independiente del número de versión del software. El código para manejar protocolos y formatos de archivo antiguos y obsoletos a menudo se considera tosco .
El software en la etapa experimental ( alfa o beta ) a menudo utiliza un cero en la primera posición ("principal") de la secuencia para designar su estado. Sin embargo, este esquema solo es útil para las primeras etapas, no para las próximas versiones con software establecido donde el número de versión ya pasó de 0. [1]
Se utilizan varios esquemas para indicar el estado de una versión más reciente:
Las dos formas puramente numéricas eliminan la lógica especial requerida para manejar la comparación de "alfa < beta < rc < sin prefijo" como se encuentra en el control de versiones semántico, a costa de la claridad.
Hay dos escuelas de pensamiento sobre cómo se incrementan los números de versión numérica. La mayoría de los paquetes de software gratuitos y de código abierto , incluido MediaWiki , tratan las versiones como una serie de números individuales, separados por puntos, con una progresión como 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc.
Por otro lado, algunos paquetes de software identifican las versiones mediante números decimales: 1,7, 1,8, 1,81, 1,82, 1,9, etc. Las versiones decimales eran comunes en los años 1980, por ejemplo con NetWare , DOS y Microsoft Windows , pero incluso en los años 2000 han sido utilizados, por ejemplo, por Opera [13] y Movable Type . [14] En el esquema decimal, 1.81 es la versión menor que sigue a 1.8, mientras que las versiones de mantenimiento (es decir, solo correcciones de errores) pueden indicarse con un sufijo alfabético, como 1.81a o 1.81b.
El esquema de numeración de versiones estándar de GNU es major.minor.revision, [15] pero Emacs es un ejemplo notable que utiliza otro esquema en el que se eliminó el número principal (1) y se agregó una revisión del sitio del usuario que siempre es cero en los paquetes originales de Emacs, pero incrementado por los distribuidores. [16] De manera similar, los números de paquetes de Debian tienen el prefijo opcional "época", que se utiliza para permitir que se cambie el esquema de versiones. [17]
En algunos casos, los desarrolladores pueden decidir restablecer el número de versión principal. A veces se utiliza para indicar que se está lanzando una nueva fase de desarrollo. Por ejemplo, Minecraft Alpha se ejecutó desde la versión 1.0.0 a 1.2.6, y cuando se lanzó Beta, restableció el número de versión principal y se ejecutó de 1.0 a 1.8. Una vez que el juego se lanzó por completo, el número de versión principal se restableció nuevamente a 1.0.0. [18]
Cuando se imprimen, las secuencias pueden estar separadas por caracteres. La elección de personajes y su uso varía según el esquema. La siguiente lista muestra ejemplos hipotéticos de esquemas de separación para la misma versión (de la decimotercera revisión de tercer nivel a la cuarta revisión de segundo nivel a la segunda revisión de primer nivel): [ ¿ investigación original? ]
Cuando se utiliza un punto para separar secuencias, puede representar o no un punto decimal; consulte la sección "Secuencias incrementales" para conocer varios estilos de interpretación.
A veces hay un cuarto número no publicado que indica la versión del software (como la utiliza Microsoft ). Adobe Flash es un caso notable en el que se indica públicamente un número de versión de cuatro partes, como en 10.1.53.64. Algunas empresas también incluyen la fecha de construcción. Los números de versión también pueden incluir letras y otros caracteres, como Lotus 1-2-3 Versión 1a.
Algunos proyectos utilizan números de versión negativos. Un ejemplo es el compilador SmartEiffel que comenzó desde −1,0 y contó hasta 0,0. [dieciséis]
Muchos proyectos utilizan un esquema de control de versiones basado en fechas llamado Calendar Versioning (también conocido como CalVer [19] ).
Ubuntu es un ejemplo de un proyecto que utiliza versiones de calendario; Ubuntu 18.04, por ejemplo, se lanzó en abril de 2018. Esto tiene la ventaja de poder relacionarse fácilmente con los cronogramas de desarrollo y los cronogramas de soporte. Algunos videojuegos también utilizan la fecha como control de versiones, por ejemplo el juego de arcade Street Fighter EX . Al inicio, muestra el número de versión como una fecha más un código de región, por ejemplo 961219 ASIA . [ cita necesaria ]
Cuando se usan fechas en el control de versiones, por ejemplo, nombres de archivos, es común usar el esquema ISO 8601 [20] AAAA-MM-DD , ya que se puede ordenar fácilmente en orden creciente o decreciente. A veces se omiten los guiones. El proyecto Wine utilizaba anteriormente un esquema de control de versiones por fecha, que utilizaba el año seguido del mes seguido del día del lanzamiento; por ejemplo, "Vino 20040505". [ cita necesaria ] Minecraft tenía una versión de formato similar, pero en su lugar usaba DDHHMM, por ejemplo: rd-132211, siendo 13 el 13 de mayo y 2211 siendo las 22:11.
Los números de compilación de Microsoft Office son una fecha codificada: [21] los primeros dos dígitos indican la cantidad de meses que han pasado desde enero del año en que comenzó el proyecto (siendo cada versión importante de Office un proyecto diferente), mientras que la última dos dígitos indican el día de ese mes. Entonces 3419 es el día 19 del mes 34 después del mes de enero del año en que comenzó el proyecto. [ cita necesaria ]
Otros ejemplos que identifican versiones por año incluyen Adobe Illustrator 88 y WordPerfect Office 2003. Cuando se utiliza un año para indicar la versión, generalmente es con fines de marketing y también existe un número de versión real. Por ejemplo, Windows 95 tiene una versión interna de MS-DOS 7.00 y Windows 4.00; Asimismo, Windows 2000 tiene una versión interna como NT 5.0. [22]
La Python Software Foundation ha publicado PEP 440 – Identificación de versión y especificación de dependencia, [23] que describe su propio esquema flexible, que define un segmento de época, un segmento de lanzamiento, segmentos previos y posteriores al lanzamiento y un segmento de lanzamiento de desarrollo.
TeX tiene un sistema de numeración de versiones idiosincrásico , una característica inusual inventada por su desarrollador Donald Knuth . Desde la versión 3.1, las actualizaciones se indican agregando un dígito adicional al final, de modo que el número de versión se acerca asintóticamente al número π . (Esta es una forma de numeración unaria ; el número de versión es el número de dígitos). A partir de febrero de 2021, el número de versión es 3.141592653. Esto es un reflejo de que TeX es muy estable y solo se anticipan actualizaciones menores. El desarrollador de TeX, Donald Knuth, ha declarado que el "cambio absolutamente final (que se realizará después de [su] muerte)" será cambiar el número de versión a π , momento en el cual todos los errores restantes se convertirán en características permanentes. [24]
De manera similar, el número de versión de Metafont se acerca asintóticamente al número de Euler, e . [24] En febrero de 2021, el número de versión es 2.71828182. Metafont también fue ideado por Donald Knuth como complemento de su sistema de composición tipográfica TeX.
Durante la era del Mac OS clásico , los números de versiones menores rara vez iban más allá de ".1". Cuando lo hacían, normalmente saltaban directamente a ".5", sugiriendo que la liberación era "más significativa". [a] Por lo tanto, "8.5" se comercializó como su propia versión, representando "Mac OS 8 y medio", y 8.6 efectivamente significaba "8.5.1".
Mac OS X se apartó de esta tendencia, en gran parte porque "X" (el número romano de 10) estaba en el nombre del producto. Como resultado, todas las versiones de OS X comenzaron con el número 10. La primera versión importante de OS X recibió el número de versión 10.0, pero la siguiente versión principal no fue la 11.0. En cambio, se numeró 10.1, seguido de 10.2, 10.3, y así sucesivamente para cada versión importante posterior. Por lo tanto, la undécima versión principal de OS X recibió la etiqueta "10.10". Aunque la "X" se eliminó del nombre a partir de macOS 10.12 , este esquema de numeración continuó hasta macOS 10.15. Según el esquema de control de versiones basado en "X", el tercer número (en lugar del segundo) denota una versión menor y actualizaciones adicionales por debajo de este nivel, así como actualizaciones de una versión principal determinada de OS X posteriores al lanzamiento de una nueva. versión principal, se denominaron Actualizaciones suplementarias. [25]
El número romano X se aprovechó simultáneamente con fines de marketing en múltiples líneas de productos. Tanto QuickTime como Final Cut Pro saltaron de la versión 7 directamente a la versión 10, QuickTime X y Final Cut Pro X. Al igual que Mac OS X, los productos no eran actualizaciones de versiones anteriores, sino programas completamente nuevos. Al igual que con OS X, las versiones principales de estos programas incrementaron el segundo dígito y las versiones menores se indicaron con un tercer dígito. La "X" se eliminó del nombre de Final Cut con el lanzamiento de macOS 11.0 (ver más abajo), y la marca QuickTime se volvió discutible cuando el marco quedó obsoleto en favor de AVFoundation en 2011 (el programa para reproducir videos QuickTime solo se llamaba QuickTime Player desde el comienzo).
La próxima versión de macOS de Apple, numerada provisionalmente 10.16, [26] se anunció oficialmente como macOS 11 en la WWDC en junio de 2020 y se lanzó en noviembre de 2020. [27] La siguiente versión de macOS, macOS Monterey , se lanzó en octubre de 2021 y superó su versión principal. número de versión a 12. [28]
El sistema operativo Microsoft Windows fue etiquetado por primera vez con números de versión estándar para Windows 1.0 hasta Windows 3.11 . Después de esto, Microsoft excluyó el número de versión del nombre del producto. Para Windows 95 (versión 4.0), Windows 98 (4.10) y Windows 2000 (5.0), el año de lanzamiento se incluyó en el título del producto. Después de Windows 2000, Microsoft creó la familia Windows Server que continuó el estilo basado en años con una diferencia: para versiones menores, Microsoft añadió el sufijo "R2" al título, por ejemplo, Windows Server 2008 R2 (versión 6.1). Este estilo se había mantenido constante hasta la fecha. Sin embargo, las versiones cliente de Windows no adoptaron un estilo consistente. Primero, recibieron nombres con sufijos alfanuméricos arbitrarios, como en Windows Me (4.90), Windows XP (5.1) y Windows Vista (6.0). Luego, una vez más Microsoft adoptó números incrementales en el título, pero esta vez no eran números de versiones; los números de versión de Windows 7 , Windows 8 y Windows 8.1 son respectivamente 6.1, 6.2 y 6.3. En Windows 10 , el número de versión saltó a 10.0 [29] y las actualizaciones posteriores del sistema operativo solo incrementaron el número de compilación y el número de revisión de compilación de actualización (UBR).
El sucesor de Windows 10, Windows 11 , se lanzó el 5 de octubre de 2021. A pesar de llevar el nombre "11", la nueva versión de Windows no aumentó su número de versión principal a 11. En cambio, permaneció en el mismo número de versión 10.0. , utilizado por Windows 10. [30]
Algunos productores de software utilizan diferentes esquemas para indicar las versiones de su software. El proyecto Debian utiliza un esquema de versiones mayor/menor para las versiones de su sistema operativo, pero utiliza nombres en clave de la película Toy Story durante el desarrollo para referirse a versiones estables, inestables y de prueba. [31]
BLAG Linux y GNU presentan números de versión muy grandes: las versiones principales tienen números como 50000 y 60000, mientras que las versiones menores aumentan el número en 1 (por ejemplo, 50001, 50002). Las versiones alfa y beta reciben números de versión decimal ligeramente menores que el número de versión principal, como 19999.00071 para la alfa 1 de la versión 20000 y 29999.50000 para la beta 2 de la versión 30000. A partir de 9001 en 2003, la versión más reciente a partir de 2011 [update]es 140000. [32] [33] [34]
Urbit utiliza el control de versiones Kelvin (llamado así por la escala absoluta de temperatura Kelvin ): las versiones de software comienzan con un número alto y cuentan hacia atrás hasta la versión 0, momento en el que el software se considera terminado y no se realizan más modificaciones. [35] [36]
El software puede tener un número de versión "interno" que difiere del número de versión que se muestra en el nombre del producto (y que normalmente sigue las reglas de numeración de versiones de manera más consistente). Java SE 5.0, por ejemplo, tiene el número de versión interna 1.5.0, y las versiones de Windows a partir de NT 4 han continuado internamente las versiones numéricas estándar: Windows 2000 es NT 5.0, XP es Windows NT 5.1, Windows Server 2003 y Windows XP Professional x64 Edition es NT 5.2, Windows Server 2008 y Vista son NT 6.0, Windows Server 2008 R2 y Windows 7 son NT 6.1, Windows Server 2012 y Windows 8 son NT 6.2, y Windows Server 2012 R2 y Windows 8.1 son NT 6.3. sin embargo, la primera versión de Windows 10 fue la 10.0 (10.0.10240). Sin embargo, tenga en cuenta que Windows NT está apenas en su quinta revisión importante, ya que su primera versión tenía el número 3.1 (para coincidir con el número de versión actual de Windows) y el lanzamiento de Windows 10 dio un salto de versión de 6.3 a 10.0.
Junto con los diversos esquemas de control de versiones enumerados anteriormente, generalmente se utiliza un sistema para indicar las versiones previas al lanzamiento, a medida que el programa avanza por las etapas del ciclo de vida del lanzamiento del software .
Los programas que se encuentran en una etapa inicial a menudo se denominan software "alfa", por la primera letra del alfabeto griego. Una vez que maduren pero aún no estén listos para su lanzamiento, se les puede llamar software "beta", por la segunda letra del alfabeto griego. Generalmente, el software alfa lo prueban únicamente los desarrolladores, mientras que el software beta se distribuye para pruebas comunitarias.
Algunos sistemas utilizan versiones numéricas inferiores a 1 (como 0,9) para sugerir su enfoque hacia una versión final "1.0". Esta es una convención común en el software de código abierto . [37] [38] Sin embargo, si la versión preliminar es para un paquete de software existente (por ejemplo, versión 2.5), entonces se puede agregar una "a" o "alfa" al número de versión. Por lo tanto, la versión alfa de la versión 2.5 podría identificarse como 2.5a o 2.5.a.
Una alternativa es referirse a las versiones previas al lanzamiento como "candidatos de lanzamiento", de modo que los paquetes de software que pronto se lanzarán como una versión particular puedan llevar esa etiqueta de versión seguida de "rc-#", que indica el número del candidato de lanzamiento. ; cuando se lanza la versión final, se elimina la etiqueta "rc".
Un tren de lanzamiento de software es una forma de cronograma de lanzamiento de software en el que una serie distinta de lanzamientos de software versionados para múltiples productos se lanzan como un número de "trenes" diferentes en un cronograma regular. Generalmente, para cada línea de productos, se ejecutan varios trenes de lanzamiento diferentes en un momento dado, y cada tren avanza desde el lanzamiento inicial hasta la madurez y el retiro eventuales en un cronograma planificado. Los usuarios pueden experimentar con un tren de lanzamiento más nuevo antes de adoptarlo para producción, lo que les permite experimentar con lanzamientos más nuevos y "en bruto" con anticipación, mientras continúan siguiendo los lanzamientos puntuales del tren anterior para sus sistemas de producción antes de pasar al nuevo tren de lanzamiento como se vuelve maduro.
La plataforma de software IOS de Cisco utilizó un programa de lanzamiento con muchos trenes distintos durante muchos años. Más recientemente, otras plataformas, incluidas Firefox y Fenix para Android, [39] Eclipse , [40] LibreOffice , [41] Ubuntu , [42] Fedora, [43] Python, [44 ] digiKam [45] y VMware [ 46] han adoptado el modelo de tren de liberación.
Entre las series 1.0 y 2.6.x, el kernel de Linux utilizó números de versión menores impares para indicar versiones de desarrollo e incluso números de versión menores para indicar versiones estables; consulte Kernel de Linux § Numeración de versiones . Por ejemplo, Linux 2.3 fue una familia de desarrollo del segundo diseño principal del kernel de Linux, y Linux 2.4 fue la familia de versiones estables en la que maduró Linux 2.3. Después del número de versión secundaria en el kernel de Linux está el número de versión, en orden ascendente; por ejemplo, Linux 2.4.0 → Linux 2.4.22. Desde el lanzamiento en 2004 del kernel 2.6, Linux ya no utiliza este sistema y tiene un ciclo de lanzamiento mucho más corto.
El mismo sistema par-impar lo utilizan otros programas con ciclos de lanzamiento largos, como Node.js hasta la versión 0.12, así como GNOME y WineHQ . [47]
Java de Sun ha tenido en ocasiones un sistema híbrido, donde el número de versión interna siempre ha sido 1. x pero se ha comercializado sólo con referencia a x :
Sun también eliminó el primer dígito para Solaris, donde Solaris 2.8 (o 2.9) se conoce como Solaris 8 (o 9) en los materiales de marketing.
Un salto similar tuvo lugar con el kit de construcción PBX de código abierto Asterisk a principios de la década de 2010, cuyos líderes de proyecto anunciaron que a la versión actual 1.8.x pronto le seguiría la versión 10. [48]
Este enfoque, criticado por muchos porque rompe el significado semántico de las secciones del número de versión, ha sido adoptado por un número cada vez mayor de proveedores, incluido Mozilla (para Firefox ).
Los números de versión evolucionan muy rápidamente desde números enteros simples (1, 2,...) a números racionales (2.08, 2.09, 2.10) y luego a "números" no numéricos como 4:3.4.3-2. Por lo tanto, es mejor tratar estos números de versión complejos como cadenas de caracteres. Los sistemas operativos que incluyen funciones de administración de paquetes (como todas las distribuciones no triviales de Linux o BSD ) utilizarán un algoritmo específico de la distribución para comparar números de versión de diferentes paquetes de software. Por ejemplo, los algoritmos de ordenamiento de Red Hat y las distribuciones derivadas difieren de los de las distribuciones tipo Debian.
Como ejemplo de comportamiento sorprendente de implementación de ordenamiento de números de versión, en Debian, los ceros iniciales se ignoran en fragmentos, de modo que 5.0005 y 5.5 se consideran iguales, y 5.5 < 5.0006. Esto puede confundir a los usuarios; las herramientas de comparación de cadenas pueden no encontrar un número de versión determinado; y esto puede causar errores sutiles en la administración de paquetes si los programadores usan estructuras de datos indexadas por cadenas, como tablas hash indexadas por número de versión .
Para facilitar la clasificación, algunos paquetes de software representan cada componente del esquema de versión mayor.menor con un ancho fijo. Perl representa sus números de versión como un número de punto flotante; por ejemplo, la versión 5.8.7 de Perl también se puede representar como 5.008007. Esto permite representar una versión teórica de 5.8.10 como 5.008010. Otros paquetes de software empaquetan cada segmento en un ancho de bits fijo; por ejemplo, en Microsoft Windows, el número de versión 6.3.9600.16384 se representaría como hexadecimal 0x0006000325804000. El esquema de punto flotante se descompone si algún segmento del número de versión excede 999; un esquema binario empaquetado que emplea 16 bits cada uno se descompone después de 65535.
Las comunidades de software libre y de código abierto tienden a lanzar software tempranamente y con frecuencia . Las versiones iniciales son números menores que 1, y estas versiones 0.x se utilizan para transmitir que el software está incompleto y no es lo suficientemente confiable para su lanzamiento general o utilizable en su estado actual. Los cambios incompatibles con versiones anteriores son comunes en las versiones 0.x. La versión 1.0 se utiliza como un hito importante , lo que indica que el software tiene al menos todas las características principales y las funciones que los desarrolladores querían incluir en esa versión, y se considera lo suficientemente confiable para su lanzamiento general. [37] [38] Un buen ejemplo de esto es el kernel de Linux, que se lanzó por primera vez como versión 0.01 en 1991, [49] y tardó hasta 1994 en alcanzar la versión 1.0.0. [50]
Los desarrolladores del emulador de juegos arcade MAME nunca tienen la intención de lanzar una versión 1.0 del programa porque siempre habrá más juegos arcade para emular y, por lo tanto, el proyecto nunca podrá completarse del todo. En consecuencia, a la versión 0.99 le siguió la versión 0.100. [51]
Desde que Internet se ha generalizado, la mayoría de los proveedores de software comercial ya no siguen la máxima de que una versión principal debe ser "completa" y, en cambio, confían en parches con correcciones de errores para solucionar los problemas conocidos para los cuales se ha encontrado una solución y se puede solucionar. [ cita necesaria ]
Una práctica relativamente común es realizar saltos importantes en los números de versión por motivos de marketing. A veces, los proveedores de software simplemente omiten la versión 1.0 o lanzan rápidamente una versión con un número de versión posterior porque muchos clientes consideran que el software 1.0 es demasiado inmaduro para confiarle implementaciones de producción. [ cita necesaria ] Por ejemplo, como en el caso de dBase II , un producto se lanza con un número de versión que implica que es más maduro de lo que es.
Otras veces, los números de versión aumentan para coincidir con los de la competencia. Esto se puede ver en muchos ejemplos de numeración de versiones de productos de Microsoft, America Online , Sun Solaris , Java Virtual Machine , SCO Unix, WordPerfect . Microsoft Access saltó de la versión 2.0 a la versión 7.0, para coincidir con el número de versión de Microsoft Word .
Microsoft también ha sido el objetivo de la actualización de versiones, ya que los navegadores Netscape se saltaron las versiones 5 a 6, en línea con Internet Explorer de Microsoft , pero también porque el conjunto de aplicaciones Mozilla heredó la versión 5 en su cadena de agente de usuario durante la versión anterior a 1.0. desarrollo y Netscape 6.x se construyó sobre la base del código de Mozilla.
Otro ejemplo de cómo mantenerse al día con la competencia es cuando Slackware Linux saltó de la versión 4 a la versión 7 en 1999. [52]
A mediados de la década de 1990, Maximo, CMMS de rápido crecimiento , pasó de Maximo Serie 3 directamente a Serie 5, saltándose la Serie 4 debido a las dificultades de marketing percibidas de ese número en el mercado chino, donde el número 4 está asociado con la "muerte" (ver tetrafobia ). Esto no impidió que se lanzara Maximo Series 5 versión 4.0. (Desde entonces, el control de versiones de la "Serie" se eliminó, restableciendo efectivamente los números de versión después del lanzamiento de la versión 1.0 de la Serie 5).
Los números de versión los utiliza en términos prácticos el consumidor o cliente para identificar o comparar su copia del producto de software con otra copia, como la versión más reciente publicada por el desarrollador. Para el programador o la empresa, el control de versiones se utiliza a menudo revisión por revisión, donde las partes individuales del software se comparan y contrastan con revisiones más nuevas o anteriores de esas mismas partes, a menudo en un sistema colaborativo de control de versiones .
En el siglo XXI, más programadores comenzaron a utilizar una política de versiones formalizada, como la política de versiones semánticas. [1] El propósito de tales políticas es hacer que sea más fácil para otros programadores saber cuándo es probable que los cambios de código rompan lo que han escrito. Estas políticas son especialmente importantes para bibliotecas y marcos de software , pero también pueden ser muy útiles para aplicaciones de línea de comandos (que pueden ser llamadas desde otras aplicaciones) y, de hecho, cualquier otra aplicación (que puede estar escrita y/o extendida por terceros). ).
El control de versiones también es una práctica necesaria para permitir muchos esquemas de parcheo y actualización de software, especialmente para decidir automáticamente qué y dónde actualizar.
Los números de versión permiten a las personas que brindan soporte determinar exactamente qué código está ejecutando un usuario, de modo que puedan descartar errores que ya se han solucionado como causa de un problema, y similares. Esto es especialmente importante cuando un programa tiene una comunidad de usuarios sustancial, especialmente cuando esa comunidad es lo suficientemente grande como para que las personas que brindan soporte técnico no sean las personas que escribieron el código. El significado semántico [1] de la numeración de estilo versión.revisión.cambio también es importante para el personal de tecnología de la información, que a menudo la utiliza para determinar cuánta atención e investigación deben prestar a una nueva versión antes de implementarla en sus instalaciones. Como regla general, cuanto mayores sean los cambios, mayores serán las posibilidades de que algo se rompa (aunque examinar el Registro de cambios, si lo hay, puede revelar sólo cambios superficiales o irrelevantes). Esta es una de las razones del disgusto expresado en el enfoque de "eliminar la versión principal" adoptado por Asterisk y otros: ahora, el personal debe (o al menos debería) hacer una prueba de regresión completa para cada actualización.
Algunos sistemas de archivos informáticos , como el sistema de archivos OpenVMS , también conservan versiones de los archivos. El control de versiones entre documentos es relativamente similar a la rutina utilizada con las computadoras y la ingeniería de software, donde con cada pequeño cambio en la estructura, el contenido o las condiciones, el número de versión se incrementa en 1, o en un valor mayor o menor, dependiendo nuevamente de las necesidades personales. preferencia del autor y el tamaño o importancia de los cambios realizados.
Los números de versión de estilo de software se pueden encontrar en otros medios.
En algunos casos, el uso es una analogía directa (por ejemplo: Jackass 2.5 , una versión de Jackass Number Two con características especiales adicionales; el segundo álbum de Garbage , titulado Version 2.0 ; o Dungeons & Dragons 3.5, donde se revisaron las reglas a partir de la tercera edición, pero no tanto como para ser considerada la cuarta).
Más a menudo se utiliza para jugar con una asociación con alta tecnología y no indica literalmente una "versión" (por ejemplo, Tron 2.0 , un videojuego que sigue a la película Tron , o la serie de televisión The IT Crowd , que se refiere a la segunda temporada como Versión 2.0). Un uso particularmente notable es la Web 2.0 , que se refiere a sitios web de principios de la década de 2000 que enfatizaban el contenido generado por el usuario , la usabilidad y la interoperabilidad .
Los archivos de software de dibujo técnico y CAD también pueden utilizar algún tipo de número de versión primitivo para realizar un seguimiento de los cambios.
Debe identificar cada versión con un par de números de versión, una versión principal y una menor.
No tenemos ningún inconveniente en utilizar más de dos números, pero es muy poco probable que realmente los necesites.