El control de versiones de software es el proceso de asignar nombres de versión únicos o números de versión únicos a estados únicos de software de computadora. Dentro de una categoría de número de versión dada (por ejemplo, principal o secundaria), estos números generalmente se asignan en orden creciente y corresponden a nuevos desarrollos en el software. En un nivel de granularidad fina, el control de revisión se utiliza para realizar un seguimiento de versiones de información que van cambiando gradualmente, ya sea que esta información sea software de computadora o no, con el fin de poder revertir cualquier cambio.
El software informático moderno suele rastrearse utilizando dos esquemas de versiones de software diferentes: un número de versión interno 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 sobre todo en la administración pública, así como en las empresas, para identificar de forma única los expedientes o casos. En el caso de los archivos informáticos, esta práctica se introdujo por primera vez con el sistema de archivos ITS del MIT, y posteriormente con el sistema de archivos TENEX para el PDP-10 en 1972. [2]
Más tarde se añadieron listas de archivos que incluían sus versiones y dependencias entre ellos. Las distribuciones Linux como Debian, con su dpkg , crearon desde el principio un software de gestión de paquetes que podía resolver 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, esta idea se invirtió, de modo que un paquete supiera los paquetes que necesitaba. Al instalar un paquete, se utilizó la resolución de dependencias para calcular automáticamente también los paquetes necesarios e instalarlos con el paquete deseado. Para facilitar las actualizaciones, se introdujeron las versiones mínimas de los paquetes. Por lo tanto, el esquema de numeración necesitaba indicar qué versión era más nueva que la requerida. [3] [4] [5]
Se han creado diversos esquemas de numeración de versiones para llevar un registro de las distintas versiones de un software. La ubicuidad de las computadoras también ha llevado a que estos esquemas se utilicen en contextos ajenos a 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 la cantidad 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 importancia y la decisión de qué secuencia cambiar entre versiones se basa en la importancia de los cambios con respecto a 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 por las líneas de código modificadas, los puntos de función añadidos 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 diseño visual, la cantidad de características nuevas o casi cualquier cosa que los desarrolladores o vendedores de productos consideren significativa, 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 versiones 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 una metaetiqueta de compilación opcional. En este esquema, el riesgo y la funcionalidad son las medidas de importancia. Los cambios importantes se indican aumentando el número principal (riesgo alto); las características nuevas que no son importantes incrementan el número secundario (riesgo medio); y todos los demás cambios que no son importantes incrementan el número del parche (riesgo más bajo). La presencia de una etiqueta de prelanzamiento (-alpha, -beta) indica un riesgo sustancial, al igual que un número principal de cero (0.yz), que se utiliza para indicar un trabajo en progreso que puede contener cualquier nivel de cambios potencialmente importantes (riesgo más alto). Como ejemplo de inferir 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 añadido características significativas, pero 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 una versión a medio camino entre las versiones principales (aunque los niveles de control de versiones basado en secuencias no están necesariamente limitados a un solo dígito, como en la versión 2.91 de Blender o Minecraft Java Edition a partir de la 1.7.10).
Un enfoque diferente es utilizar los números mayores y menores junto con una cadena alfanumérica que denota el tipo de versión, por ejemplo, "alfa" (a), "beta" (b) o "candidato a versión" (rc). Un tren de versiones 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 características y cambios importantes durante las fases de candidatas a versión y, para algunos equipos, incluso las versiones beta se bloquean solo para correcciones de errores, para garantizar la convergencia en la versión objetivo.
Otros esquemas imparten significado a secuencias individuales:
Nuevamente, en estos ejemplos, la definición de lo que constituye un cambio "importante" en oposición a un cambio "menor" es completamente subjetiva y depende del autor, como también lo es lo que define una "compilación" o cómo una "revisión" se diferencia de un 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 de nomenclatura de versiones existe en la publicación de libros, donde los números o nombres de las ediciones pueden elegirse basándose en diversos criterios.
En la mayoría de los programas propietarios, la primera versión publicada de un producto de software es la versión 1. [ cita requerida ]
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 software nuevo 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 restaura al servicio. [12]
A menudo, los encabezados de los paquetes y los formatos de archivo incluyen un número de versión, a veces el mismo que el número de versión del software que los escribió; otras veces, un "número de versión del protocolo" independiente del número de versión del software. El código para manejar protocolos y formatos de archivo obsoletos se suele considerar como basura .
El software en etapa experimental ( alfa o beta ) suele utilizar un cero en la primera posición ("principal") de la secuencia para indicar su estado. Sin embargo, este esquema solo es útil para las primeras etapas, no para los próximos lanzamientos de software establecido donde el número de versión ya ha superado el 0. [1]
Se utilizan varios esquemas para indicar el estado de una versión más nueva:
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 la versión semántica, a costa de la claridad.
Existen dos escuelas de pensamiento sobre cómo se incrementan los números de versión numéricos. La mayoría de los paquetes de software libre 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 con números decimales: 1.7, 1.8, 1.81, 1.82, 1.9, etc. Las versiones decimales eran comunes en la década de 1980, por ejemplo con NetWare , DOS y Microsoft Windows , pero incluso en la década de 2000 han sido utilizadas, 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 denotarse con un sufijo alfabético, como 1.81a o 1.81b.
El esquema de numeración de versiones estándar de GNU es mayor.menor.revisión, [15] pero Emacs es un ejemplo notable que utiliza otro esquema donde se eliminó el número mayor (1) y se agregó una revisión del sitio del usuario que siempre es cero en los paquetes originales de Emacs pero que se incrementa en los distribuidores. [16] De manera similar, los números de paquetes de Debian tienen como prefijo una "época" opcional, 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. Esto se utiliza a veces para indicar que se lanza una nueva fase de desarrollo. Por ejemplo, Minecraft Alpha se ejecutó desde la versión 1.0.0 hasta la 1.2.6, y cuando se lanzó Beta, se restableció el número de versión principal y se ejecutó desde la 1.0 hasta la 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]
Al imprimir, las secuencias pueden estar separadas por caracteres. La elección de caracteres 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 y a la segunda revisión de primer nivel): [ ¿Investigación original? ]
Cuando se utiliza un punto para separar secuencias, puede o no representar un punto decimal; consulte la sección "Incremento de secuencias" para conocer varios estilos de interpretación.
A veces hay un cuarto número no publicado que indica la versión del software (tal como lo 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 compilación. Los números de versión también pueden incluir letras y otros caracteres, como Lotus 1-2-3 Release 1a.
Algunos proyectos utilizan números de versión negativos. Un ejemplo es el compilador SmartEiffel , que empezaba desde −1.0 y contaba hacia arriba hasta 0.0. [16]
Muchos proyectos utilizan un esquema de control de versiones basado en fechas llamado Control de versiones de calendario (también conocido como CalVer [19] ).
Ubuntu es un ejemplo de un proyecto que utiliza el control de versiones con calendario; Ubuntu 18.04, por ejemplo, se lanzó en abril de 2018. Esto tiene la ventaja de que se relaciona fácilmente con los cronogramas de desarrollo y los plazos de soporte. Algunos videojuegos también utilizan la fecha como control de versiones, por ejemplo, el juego arcade Street Fighter EX . Al iniciarse, muestra el número de versión como una fecha más un código de región, por ejemplo, 961219 ASIA . [ cita requerida ]
Al usar fechas en el control de versiones, por ejemplo, en los nombres de archivos, es común usar el esquema ISO 8601 [20] AAAA-MM-DD , ya que se puede ordenar fácilmente en cadenas en orden creciente o decreciente. A veces se omiten los guiones. El proyecto Wine anteriormente usaba un esquema de control de versiones de fecha, que usaba el año seguido del mes seguido del día del lanzamiento; por ejemplo, "Wine 20040505". [ cita requerida ] Minecraft tenía un formato de versión similar, pero en su lugar usaba DDHHMM, ej: rd-132211, 13 siendo el 13 de mayo y 2211 siendo 22:11.
Los números de compilación de Microsoft Office son una fecha codificada: [21] los dos primeros dígitos indican la cantidad de meses que han transcurrido desde enero del año en que comenzó el proyecto (cada versión principal de Office es un proyecto diferente), mientras que los dos últimos dígitos indican el día de ese mes. Por lo tanto, 3419 es el día 19 del mes 34 después del mes de enero del año en que comenzó el proyecto. [ cita requerida ]
Otros ejemplos que identifican las 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 versiones internas como MS-DOS 7.00 y Windows 4.00; de la misma manera, Windows 2000 tiene versiones internas como NT 5.0. [22]
La Python Software Foundation ha publicado PEP 440 – Version Identification and Dependency Specification, [23] describiendo su propio esquema flexible, que define un segmento de época, un segmento de lanzamiento, segmentos previos al lanzamiento 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 han indicado 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 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 que todos los errores restantes se convertirán en características permanentes. [24]
De manera similar, el número de versión de Metafont se aproxima asintóticamente al número de Euler, e . [24] A 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", lo que sugería que la versión era "más significativa". [a] Por lo tanto, "8.5" se comercializaba como una versión propia, lo que representaba "Mac OS 8 y medio", y 8.6 significaba efectivamente "8.5.1".
Mac OS X se apartó de esta tendencia, en gran parte porque "X" (el número romano para 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 importante no fue 11.0. En su lugar, se numeró 10.1, seguida 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 se etiquetó como "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. Bajo el esquema de versiones basado en "X", el tercer número (en lugar del segundo) denotaba una versión menor, y las actualizaciones adicionales por debajo de este nivel, así como las actualizaciones a una versión principal determinada de OS X que venían después del lanzamiento de una nueva versión principal, se titulaban Actualizaciones complementarias. [25]
El número romano X se utilizó simultáneamente con fines de marketing en varias líneas de productos. Tanto QuickTime como Final Cut Pro pasaron de la versión 7 directamente a la versión 10, QuickTime X y Final Cut Pro X. Al igual que el propio 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 aumentaron el segundo dígito y las versiones menores se denotaron utilizando un tercer dígito. La "X" se eliminó del nombre de Final Cut con el lanzamiento de macOS 11.0 (ver a continuación), y la marca QuickTime dejó de ser relevante cuando el marco quedó obsoleto en favor de AVFoundation en 2011 (el programa para reproducir videos QuickTime solo se llamó QuickTime Player desde el principio).
La siguiente 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 aumentó su número de versión principal 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 a 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 el año con una diferencia: para lanzamientos menores, Microsoft agregó el sufijo "R2" al título, por ejemplo, Windows Server 2008 R2 (versión 6.1). Este estilo se había mantenido consistente hasta esta fecha. Sin embargo, las versiones cliente de Windows no adoptaron un estilo consistente. Primero, recibieron nombres con sufijos alfanuméricos arbitrarios como con 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 versión; 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 llamarse "11", la nueva versión de Windows no aumentó su número de versión principal a 11. En cambio, se mantuvo en el mismo número de versión de 10.0, utilizado por Windows 10. [30]
Algunos productores de software utilizan diferentes esquemas para designar 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 código de la película Toy Story durante el desarrollo para referirse a las versiones estables, inestables y en pruebas. [31]
BLAG Linux y GNU tienen 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 tienen números de versión decimales ligeramente menores que el número de la 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. Comenzando con 9001 en 2003, la versión más reciente a partir de 2011 [actualizar]es 140000. [32] [33] [34]
Urbit utiliza el sistema de versiones Kelvin (llamado así por la escala de temperatura absoluta Kelvin ): las versiones del 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 forma más coherente). Java SE 5.0, por ejemplo, tiene el número de versión interno 1.5.0, y las versiones de Windows a partir de NT 4 han continuado con las versiones numéricas estándar internamente: Windows 2000 es NT 5.0, XP es Windows NT 5.1, Windows Server 2003 y Windows XP Professional x64 Edition son 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. Inicialmente, Windows 10 iba a ser NT 6.4, ya que la primera versión preliminar técnica compartida con el público tiene el número 6.4.9841. Sin embargo, eso no duró mucho, ya que la versión de Windows 10 se aumentó rápidamente de forma artificial a 10.0 [37] para alinearse con el nombre comercial, lo que dio como resultado que la primera versión lanzada del sistema operativo tuviera el número 10.0.10240. Sin embargo, tenga en cuenta que Windows NT solo está en su quinta revisión importante, ya que su primera versión se numeró 3.1 (para que coincidiera con el número de versión de Windows vigente en ese momento) y el lanzamiento de Windows 10 hizo que la versión 6.3 saltara a 10.0.
Junto con los diversos esquemas de versiones enumerados anteriormente, generalmente se utiliza un sistema para indicar versiones previas al lanzamiento, a medida que el programa avanza a través de las etapas del ciclo de vida del lanzamiento del software .
Los programas que se encuentran en una etapa temprana suelen denominarse software "alfa", por la primera letra del alfabeto griego. Una vez que maduran pero aún no están listos para su lanzamiento, pueden denominarse software "beta", por la segunda letra del alfabeto griego. Por lo general, el software alfa es probado únicamente por desarrolladores, mientras que el software beta se distribuye para que la comunidad lo pruebe.
Algunos sistemas utilizan versiones numéricas menores que 1 (como 0.9) para sugerir su aproximación hacia una versión final "1.0". Esta es una convención común en el software de código abierto . [38] [39] Sin embargo, si la versión preliminar es para un paquete de software existente (por ejemplo, la versión 2.5), entonces se puede agregar una "a" o "alpha" 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 a 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 a lanzamiento; cuando se lanza la versión final, se elimina la etiqueta "rc".
Un tren de lanzamiento de software es una forma de programa de lanzamiento de software en el que se lanzan varias series distintas de lanzamientos de software con versiones para varios productos como una serie 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 pasa del lanzamiento inicial a la madurez final y el retiro según 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, "en bruto", de manera temprana, mientras continúan siguiendo los lanzamientos puntuales del tren anterior para sus sistemas de producción antes de pasar al nuevo tren de lanzamiento a medida que madura.
La plataforma de software IOS de Cisco utilizó un programa de tren de lanzamiento con muchos trenes distintos durante muchos años. Más recientemente, varias otras plataformas, incluidas Firefox y Fenix para Android, [40] Eclipse , [41] LibreOffice , [42] Ubuntu , [43] Fedora, [44] Python, [45] digiKam [46] y VMware [47] han adoptado el modelo de tren de lanzamiento.
Entre las series 1.0 y 2.6.x, el núcleo Linux utilizó números de versión menores impares para indicar las versiones de desarrollo y números de versión menores pares para indicar las versiones estables. Por ejemplo, Linux 2.3 fue una familia de desarrollo del segundo diseño principal del núcleo 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 menor en el núcleo Linux está el número de versión, en orden ascendente; por ejemplo, Linux 2.4.0 → Linux 2.4.22. Desde el lanzamiento del núcleo 2.6 en 2004, Linux ya no utiliza este sistema y tiene un ciclo de lanzamiento mucho más corto.
El mismo sistema de pares e impares es utilizado por otros programas con ciclos de lanzamiento largos, como Node.js hasta la versión 0.12, así como GNOME y WineHQ . [48]
El 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 de Solaris, ya que en los materiales de marketing se hace referencia a Solaris 2.8 (o 2.9) como Solaris 8 (o 9).
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 del proyecto anunciaron que la versión actual 1.8.x pronto sería seguida por la versión 10. [49]
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 simples números enteros (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 gestió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 los números de versión de diferentes paquetes de software. Por ejemplo, los algoritmos de ordenación de Red Hat y distribuciones derivadas difieren de los de las distribuciones tipo Debian.
Como ejemplo de un comportamiento sorprendente en la implementación del orden de los números de versión, en Debian, los ceros iniciales se ignoran en los 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 gestión de paquetes si los programadores utilizan 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 mayor.menor.versión 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 que una versión teórica de 5.8.10 se represente 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 deja de funcionar si algún segmento del número de versión supera 999; un esquema binario empaquetado que emplee 16 bits cada uno deja de funcionar después de 65535.
Las comunidades de software libre y de código abierto tienden a lanzar software de manera temprana y con frecuencia . Las versiones iniciales son números menores que 1, y estas versiones 0.x se usan 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 con las versiones 0.x. La versión 1.0 se usa como un hito importante , lo que indica que el software tiene al menos todas las características principales más las funciones que los desarrolladores querían incluir en esa versión, y se considera lo suficientemente confiable para su lanzamiento general. [38] [39] Un buen ejemplo de esto es el kernel de Linux, que se lanzó por primera vez como versión 0.01 en 1991, [50] y tardó hasta 1994 en alcanzar la versión 1.0.0. [51]
Los desarrolladores del emulador de juegos arcade MAME no tienen intención de lanzar nunca una versión 1.0 del programa porque siempre habrá más juegos arcade que emular y, por tanto, el proyecto nunca podrá completarse por completo. Por ello, a la versión 0.99 le siguió la versión 0.100. [52]
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 resolver los problemas conocidos para los que se ha encontrado una solución y se podría arreglar. [ cita requerida ]
Una práctica relativamente común es realizar grandes saltos en los números de versión por razones de marketing. A veces, los proveedores de software simplemente pasan por alto 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 como para confiarle las implementaciones de producción. [ cita requerida ] 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.
En otras ocasiones, los números de versión se incrementan para que coincidan 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 pasó de la versión 2.0 a la versión 7.0 para que coincida con el número de versión de Microsoft Word .
Microsoft también ha sido objeto de versiones de "actualización", con los navegadores Netscape saltándose la versión 5 a la 6, en línea con Internet Explorer de Microsoft , pero también porque la suite de aplicaciones Mozilla heredó la versión 5 en su cadena de agente de usuario durante el desarrollo anterior a la 1.0 y Netscape 6.x se construyó sobre la base de código de Mozilla.
Otro ejemplo de cómo mantenerse a la par con los competidores fue cuando Slackware Linux pasó de la versión 4 a la versión 7 en 1999. [53]
A mediados de los años 90, el sistema de gestión de máquinas de gestión (CMMS ) Maximo, que estaba creciendo rápidamente, pasó de la Serie 3 de Maximo directamente a la Serie 5, omitiendo la Serie 4 debido a las dificultades percibidas de comercialización de ese número en el mercado chino, donde el número 4 se asocia con la "muerte" (véase tetrafobia ). Esto no impidió que se lanzara la versión 4.0 de la Serie 5 de Maximo. (Desde entonces, se ha eliminado la versión "Serie", lo que restableció efectivamente los números de versión después del lanzamiento de la versión 1.0 de la Serie 5).
En la práctica, los números de versión son utilizados por 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 más antiguas de esas mismas partes, a menudo en un sistema de control de versiones colaborativo .
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 estas políticas es facilitar que otros programadores sepan cuándo es probable que los cambios en el código rompan lo que han escrito. Estas políticas son especialmente importantes para las bibliotecas y los marcos de trabajo de software , pero también pueden ser muy útiles para las aplicaciones de línea de comandos (que pueden ser llamadas desde otras aplicaciones) y, de hecho, cualquier otra aplicación (que puede estar programada 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 técnico determinar exactamente qué código está ejecutando un usuario, de modo que puedan descartar errores que ya se han corregido 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 lo usa 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 pueda fallar (aunque examinar el registro de cambios, si lo hay, puede revelar solo cambios superficiales o irrelevantes). Esta es una de las razones de parte del desagrado expresado en el enfoque de "abandonar la versión principal" adoptado por Asterisk et alia: 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 mantienen versiones de los archivos. El control de versiones entre documentos es relativamente similar a la rutina que se utiliza en las computadoras y en 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 más pequeño o más grande, nuevamente dependiendo de la preferencia personal del autor y del tamaño o la importancia de los cambios realizados.
Los números de versión de estilo 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 las reglas fueron revisadas 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 la 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 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 secundaria. No tenemos objeción a utilizar más de dos números, pero es muy poco probable que realmente los necesite.