Notas sobre el número de versión del software
La administración 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 (p. ej., mayor o menor), estos números generalmente se asignan en orden creciente y corresponden al desarrollo continuo del software. En un nivel granular, el control de versiones se usa para rastrear diferentes versiones de información, ya sea software de computadora o no, para que cualquier cambio pueda revertirse.
El software de computadora moderno generalmente se rastrea utilizando dos programas de versiones de software diferentes: números de compilación, que pueden incrementarse muchas veces al día, como números de control de revisión, y versiones de lanzamiento, que generalmente cambian con mucha menos frecuencia, como un número de versión semánticamente compatible o código de proyecto nombre.
Los números de documento se utilizan especialmente en las administraciones públicas, así como en las empresas para identificar de forma única documentos o casos. Para los archivos de computadora, la práctica se introdujo por primera vez en el sistema de archivos ITS del MIT, y luego se desarrolló el sistema de archivos TENEX para el PDP-10 en 1972.
La lista de archivos se agregó más tarde, incluidas sus versiones y las dependencias entre ellos. Las distribuciones de Linux como Debian, con dpkg entre ellas, han creado durante mucho tiempo un software de administración de paquetes que resuelve las dependencias entre sus paquetes. En el primer intento de Debian, un paquete conoce otros paquetes que dependen de él. A partir de 1994, se invirtió la idea, con un paquete sabiendo los paquetes que necesitaba. Cuando se instala un paquete, los paquetes necesarios se determinan automáticamente a través de la resolución de dependencias y se instalan junto con los paquetes necesarios. Para facilitar las actualizaciones de software, es deseable introducir cambios mínimos en la versión del paquete. Por lo tanto, el esquema de numeración debe poder decir cuál es la versión más reciente y compatible.
En un esquema de control de versiones de software basado 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. Pero los diferentes esquemas varían ampliamente en aspectos como el número de secuencias, el significado de una sola secuencia y cómo se incrementa la secuencia.
En algunos esquemas, se utilizan identificadores basados en secuencias para expresar la importancia de los cambios entre versiones. Los cambios se ordenan por nivel de importancia, y la secuencia que determina qué cambios se modifican entre versiones es la importancia de los cambios con respecto a la versión anterior, por lo que la primera secuencia se cambia como el cambio más importante y los posteriores a la primera secuencia A el cambio representa una disminución en la importancia.
Según el escenario, la importancia se puede medir en términos de líneas de código cambiadas, puntos de funcionalidad agregados o eliminados, impacto potencial en los clientes (trabajo requerido para adoptar la nueva versión), errores o roturas no anunciadas Riesgo de cambio sexual, grado de cambio en el diseño visual, la cantidad de funciones nuevas o casi cualquier cosa que un desarrollador de productos o un comercializador considere importante, incluido el deseo de marketing de enfatizar que una nueva versión es "mejor que la anterior".
definición específica
La definición general del número de versión es un número mayor y un número menor, que pueden ir seguidos de la codificación de la información correspondiente, como el número de compilación, el número de revisión (número en el Sistema de control de código fuente), el número de versión, la marca de tiempo, el número de parche y las correcciones de problemas de seguridad. número o número personalizado (compilación, revisión, lanzamiento, marca de fecha, revisión, corrección de seguridad, a cualquier algoritmo personalizado). Por ejemplo, la definición de versión de .Net 4.0 es Major.Minor.Build.Revision y es Major.Minor.Release.Build en Delphi.
En el archivo C# AssemblyInfo.cs, las definiciones relevantes son las siguientes:
// La información de versión de un ensamblado consta de los siguientes cuatro valores:
//
// Versión principal
// Versión menor
// Número de compilación
// Revisión
//
/ Puede especificar todos los valores o puede predeterminar los números de compilación y revisión
// usando el '*' como se muestra a continuación:
// [ensamblado: AssemblyVersion("1.0.*")]
El formato más utilizado para los números de versión es:
xyz (mayor.menor.construcción)
x es el número de versión principal, que representa cambios en las funciones principales, interfaces o interfaces, cambios en la arquitectura de la pila de aplicaciones, modificaciones en la infraestructura de la plataforma o cambios en la interfaz de red expuesta que puede afectar la compatibilidad;
y representa números de versión menores, cambios de funciones menores, mejoras menores (como cambios en la arquitectura local), correcciones de errores o actualizaciones internas, ajustes generales de la interfaz de usuario, adiciones o actualizaciones de componentes y cambios de API; es posible que diferentes componentes del mismo producto no puedan para trabajar juntos si los números de versión secundaria son diferentes;
z es el número de compilación (número de compilación), que generalmente se ve en la ventana "acerca de" del software, que se usa para proporcionar información detallada en la atención al cliente. Este es un formato libre, cada producto se puede definir por separado. Podría ser 1 diario, 1 por versión o 1 por compilación. El número de compilación también se puede usar como un número de versión preliminar. Este número sigue cambiando. Cuando alcanza un cierto nivel, activará el lanzamiento de una nueva versión secundaria.
Cuando cambie el número de versión del software, mantenga el mismo o aumente el número de versión de los componentes que contiene. Puede compartir un número de versión para todos los componentes o solo puede incrementar el número de versión del componente que ha cambiado.
Si es un software con una base de datos:
1. El primer número indica la versión de todo el sistema, que generalmente se cambia solo una vez cada pocos años. Por lo general, representa un cambio fundamental en la tecnología, o una función utilizada por los clientes, o ambos.
2, el segundo número indica la revisión del modelo de base de datos. Aumentar este número requeriría una migración de la base de datos, por lo que es un cambio importante que podría requerir una copia de seguridad del sistema, por lo que cambiar la estructura de la base de datos requeriría un proceso de actualización cuidadoso. Se restablece a 0 si cambia el primer número.
3. El tercer número indica un cambio puramente de software. Por lo general, esto lo puede hacer el cliente en el lado del cliente, ya que la estructura de la base de datos no ha cambiado. Se restablece a 0 si cambia el segundo número.
4. El número de versión de Subversion. Por ejemplo, use la herramienta TortoiseSVN para completar automáticamente este número en el momento de la compilación. Este número nunca se reinicia, sino que sigue aumentando. Con este número, se puede recrear cualquier versión en cualquier momento.
Si no necesita realizar un seguimiento de las revisiones de la base de datos, puede usar números de versión de 3 o 2 dígitos, que es más simple. (Esto es similar al número de compilación, y el formato de información de este número se puede determinar según la situación)
1. Primer número = Era general del sistema. Cambia cada dos años y, por lo general, representa un cambio fundamental en la tecnología, las características del cliente o ambos.
2. Segundo número = revisión del esquema de la base de datos. Un incremento en este número requiere una migración de la base de datos y, por lo tanto, es un cambio significativo (o los sistemas se replican y, por lo tanto, cambiar la estructura de la base de datos requiere un proceso de actualización cuidadoso). Se restablece a 0 si cambia el primer número.
3. Tercer número = solo cambio de software. Por lo general, esto se puede implementar cliente por cliente, ya que el esquema de la base de datos no se modifica. Se restablece a cero si cambia el segundo número.
4. Número de versión de Subversion. Completamos esto automáticamente en la compilación usando la herramienta TortoiseSVN. Este número nunca se reinicia sino que aumenta continuamente. Usando esto, siempre podemos recrear cualquier versión.
Este sistema nos está sirviendo bien porque cada número tiene una función clara e importante. He visto a otros equipos lidiando con la pregunta de número mayor/número menor (cuán grande es un cambio mayor) y no veo el beneficio de eso. Si no necesita realizar un seguimiento de las revisiones de la base de datos, simplemente vaya a un número de versión de 3 o 2 dígitos y ¡haga la vida más fácil!
Versionado semántico
Hay una especificación para Versiones Semánticas: Versiones Semánticas [semver2.0] en: Versiones Semánticas 2.0.0 | Versiones Semánticas .
El control de versiones semántico (también conocido como SemVer) es un esquema de control de versiones ampliamente adoptado que utiliza un número de versión de tres partes (Major.Minor.Patch), una etiqueta de prelanzamiento opcional y una metaetiqueta de compilación opcional (metaetiqueta de compilación opcional) para codificar la versión. En este enfoque, el riesgo y la funcionalidad son los criterios para medir el impacto de los cambios de software. Los cambios importantes se indican incrementando el número de la versión principal (alto riesgo); las funciones nuevas que no son importantes aumentan el número de la versión secundaria (riesgo medio); y todos los demás cambios no importantes aumentan el número de parche (riesgo más bajo). La presencia de etiquetas previas al lanzamiento (-alfa, -beta) indica un riesgo significativo, al igual que un número de versión principal de cero (0.yz), que se utiliza para indicar un trabajo en curso que puede contener cualquier grado de cambio destructivo potencial. (mayor riesgo). Como ejemplo de compatibilidad inferida de las versiones de SemVer, el software que se basa en una API de la versión 2.1.5 es compatible con la versión 2.2.3, pero no necesariamente con la versión 3.2.4.
Los desarrolladores pueden optar por omitir varias versiones secundarias a la vez para indicar adiciones de funciones importantes, pero no lo suficiente como para garantizar un aumento en el número de versiones principales; 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 una actualización para los usuarios del software o, como en el caso de Adobe, para representar una versión entre versiones principales (aunque los niveles de versiones basados en serie no están necesariamente limitados a un solo número, como en Blender). versión 2.91 o Minecraft Java Edition desde 1.7.10).
Un enfoque diferente es usar números mayores y menores y una cadena alfanumérica que indique el tipo de versión, como "alfa" (a), "beta" (b) o "candidato de versión" (rc). Un tren de lanzamiento de software que use este enfoque podría verse como 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 (si es lo suficientemente estable), 1.0rc2 (si se encuentran más errores) → 1.0. En este plan, es una práctica común bloquear nuevas funciones y cambios importantes en la etapa candidata a lanzamiento, y para algunos equipos, incluso la versión beta está bloqueada para permitir solo correcciones de errores para garantizar la coherencia con la versión final.
Otros esquemas asignan significado a secuencias individuales:
mayor.menor[.compilación[.revisión]] (p. ej.: 1.2.12.102)
mayor.menor[.mantener[.construir]] (por ejemplo, 1.4.3.5249).
Además, en estos ejemplos, la definición de lo que constituye un cambio "mayor" versus "menor" es completamente subjetiva y depende del autor, al igual que lo que se define como una "construcción" o la distinción entre "revisado" y "menor". cambios
Las bibliotecas compartidas para Solaris y Linux pueden usar el formato current.revision.age, donde:
actual: el último número de interfaz implementado por la biblioteca.
revisión: el número de implementación de la interfaz actual.
edad: La diferencia entre la interfaz más nueva y la más antigua implementada por la biblioteca. Este uso del tercer campo es específico de libtool: otros pueden usar un significado diferente o simplemente ignorarlo.
Problemas similares de cambio relativo en el significado y el nombre de la versión existen en la publicación de libros, donde los números de versión o los nombres se pueden elegir de acuerdo con diferentes criterios.
En la mayoría del software propietario, la primera versión lanzada del producto de software es la versión 1.
Compatibilidad (Grado de compatibilidad)
Algunos proyectos usan números de versión principal para indicar versiones incompatibles. Dos ejemplos son Apache Portable Runtime (APR) y FarCry CMS.
Por lo general, el nuevo software escrito por programadores es compatible con versiones anteriores, es decir, el nuevo software está diseñado para funcionar con versiones anteriores del software (usando protocolos y formatos de archivo más antiguos) y la versión más reciente (usando los protocolos y formatos de archivo más recientes) interactúan correctamente. . Por ejemplo, IBM z/OS se diseñó para ejecutar tres versiones principales consecutivas del sistema operativo dentro del mismo sysplex. Esto permite que alguien que administre un clúster de computadoras de alta disponibilidad mantenga la mayoría de las máquinas en funcionamiento mientras apaga, actualiza y vuelve a poner en servicio una máquina a la vez.
A menudo, los encabezados de los paquetes y los formatos de archivo incluyen un número de versión, a veces el mismo número de versión en el que se escribió el software; otras veces, un "número de versión de protocolo" separado del número de versión del software. El código que trata con protocolos y formatos de archivo obsoletos antiguos a menudo se considera una molestia.
Especificación del número de versión de la etapa de desarrollo (Designación de la etapa de desarrollo)
El software que se encuentra en una etapa experimental (alfa o beta) generalmente usa un 0 en la primera posición ("principal") de la secuencia para designar su estado. Sin embargo, esta solución solo es útil para la etapa inicial y no es adecuada para el software maduro que está a punto de ser lanzado y cuyo número de versión ha excedido 0.
Se utilizan algunos esquemas para representar el estado de las versiones más nuevas:
Los sufijos alfanuméricos son un esquema común empleado por el control de versiones semántico. En este esquema, cada versión se adjunta con un guión y algunos caracteres alfanuméricos para indicar el estado.
Un estado digital es un esquema que usa números para representar un estado como si fuera parte de una secuencia. Una opción típica es el tercer dígito de la versión de cuatro dígitos.
Digital 90+ es otro esquema que usa números, pero obviamente bajo los números de la versión anterior. Use un número grande en la última posición, generalmente 90 o más. Esto es a menudo utilizado por proyectos de código abierto más antiguos como Fontconfig.
Por ejemplo, cuando se va a lanzar la versión 1.2, la versión preliminar es 1.1.90 o un número mayor.
| Comparación de indicadores de etapa de desarrollo |
|||
| Desarrollo |
Semántico |
Numérico |
Numérico |
| escenario |
versionado |
estado |
90+ |
| Alfa |
1.2.0-a.1 |
1.2.0.1 |
1.1.90 |
| Beta |
1.2.0-b.2 |
1.2.1.2 |
1.1.93 |
| Versión candidata (RC) |
1.2.0-rc.3 |
1.2.2.3 |
1.1.97 |
| Liberar |
1.2.0 |
1.2.3.0 |
1.2.0 |
| Correcciones posteriores al lanzamiento |
1.2.5 |
1.2.3.5 |
1.2.5 |
Estas dos formas puramente numéricas eliminan la lógica especial necesaria para manejar las comparaciones de "alfa < beta < rc < sin prefijo", que se encuentra en el control de versiones semántico, a costa de una menor claridad.
Secuencias incrementales
Hay dos escuelas de pensamiento sobre cómo se incrementa el número de versión digital. La mayoría de los paquetes de software gratuitos y de código abierto, incluido MediaWiki, tratan los números de versión como una serie de números individuales, separados por puntos, incrementados de la siguiente manera: 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 identifican las versiones por 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, como NetWare, DOS y Microsoft Windows, pero incluso en la década de 2000, Opera y Movable Type estaban en uso. En el esquema decimal, 1.81 es una versión menor después de 1.8, mientras que las versiones de mantenimiento (es decir, solo correcciones de errores) pueden indicarse con un sufijo de una sola letra, como 1.81a o 1.81b.
El esquema de numeración de versión estándar de GNU es major.minor.revision, pero Emacs es un ejemplo notable que utiliza un esquema alternativo donde se elimina el número principal y se agrega una revisión del sitio del usuario, en el paquete original de Emacs siempre es 0, pero se incrementa por el distribuidor. Además, los números de paquetes de Debian tienen el prefijo "época" opcional, que se utiliza para permitir cambios en el esquema de control de versiones.
Reiniciar
En algunos casos, un desarrollador puede decidir restablecer el número de versión principal. Esto se usa a veces para indicar que se está lanzando una nueva etapa de desarrollo. Por ejemplo, Minecraft Alpha se ejecutó desde la versión 1.0.0 a la 1.2.6, y cuando se lanzó la versión beta, restableció el número de la versión principal para ejecutarse desde la 1.0 a la 1.8. Una vez que el juego se lanza por completo, el número de versión principal se restablece a 1.0.0 nuevamente.
Separando secuencias
Al imprimir, las secuencias se pueden separar por caracteres. La elección de los personajes y su uso varía de un esquema a otro. La siguiente lista muestra ejemplos hipotéticos de esquemas de separación para la misma versión (decimotercera revisión de tercer nivel a cuarta revisión de segundo nivel a segunda revisión de primer nivel):
Un esquema puede usar los mismos caracteres entre todas las secuencias: 2.4.13, 2/4/13, 2-4-13
Un protocolo puede ser inconsistente en su elección de qué secuencias separar, separando algunas secuencias pero no otras: 2.413
Un esquema puede tener una elección inconsistente de caracteres dentro del mismo identificador: 2.4_13 (por ejemplo, Minecraft Beta aumentó de 1.7 a 1.7_01 a 1.7.2)
Cuando se usa un punto para separar una secuencia, puede o no representar un punto decimal, y si es un número decimal, no es un punto decimal.
Número de secuencias
A veces también hay un cuarto número no publicado que indica la compilación del software (como lo usa Microsoft). Adobe Flash es un ejemplo notable, con cuatro números de versión indicados públicamente, como 10.1.53.64. Algunas empresas también incluyen fechas de construcción. Los números de versión también pueden incluir letras y otros caracteres, como Lotus 1-2-3 Release 1a.
Números negativos
Algunos proyectos usan números de versión negativos. Un ejemplo es el compilador SmartEiffel, que comienza en -1,0 y cuenta hasta 0,0.
Fecha de lanzamiento
Una pantalla de presentación de Street Fighter EX que muestra el número de lanzamiento en formato CalVer: "961219 USA"
Muchos proyectos utilizan un esquema de control de versiones basado en fechas llamado Control de versiones de calendario (también conocido como CalVer).
Ubuntu es un ejemplo de un proyecto que utiliza la gestión de versiones de calendario; por ejemplo, Ubuntu 18.04 se lanzó en abril de 2018. Esto tiene la ventaja de vincularse fácilmente con el cronograma de desarrollo y el cronograma de soporte. Algunos videojuegos también usan fechas como identificadores de versión, como el juego de arcade Street Fighter EX. Al iniciar, muestra el número de versión como una fecha seguida de un código de área, por ejemplo, 961219 ASIA.
Cuando se usan fechas en el control de versiones, por ejemplo, nombres de archivo, generalmente se usa el esquema ISO 8601 AAAA-MM-DD, ya que esto facilita la clasificación de cadenas en orden creciente o decreciente. A veces se omiten los guiones. El proyecto Wine solía usar un esquema de control de versiones fechado, que usaba el año, seguido del mes y luego la fecha de lanzamiento; por ejemplo, "Wine 20040505". Minecraft tiene un formato de versión similar, pero usa DDHHMM en su lugar, por ejemplo: rd-132211, 13 es 13 de mayo, 2211 es 22:11.
Un número de compilación para Microsoft Office es una fecha codificada: los dos primeros dígitos indican el mes 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 del mes. Por lo tanto, 3419 se refiere al día 19 del mes 34 contado a partir de enero del año en que se inició el proyecto.
Otros ejemplos de versiones marcadas por año incluyen Adobe Illustrator 88 y WordPerfect Office 2003. Cuando se usa un año para indicar una versión, generalmente es con fines de marketing y también hay un número de versión real. Por ejemplo, las compilaciones para Windows 95 son MS-DOS 7.00 y Windows 4.00; asimismo, las compilaciones para Windows 2000 son NT 5.0.
Otros programas
Algunos productores de software utilizan diferentes esquemas para representar sus versiones de software. El proyecto Debian usa un esquema de lanzamiento mayor/menor para los lanzamientos de su sistema operativo, pero usa nombres en clave de la película Toy Story para referirse a lanzamientos estables, inestables y de prueba durante el desarrollo.
BLAG Linux y GNU se caracterizan por números de versión muy grandes: las versiones principales tienen números como 50000 y 60000, mientras que los números de versión secundaria aumentan en 1 (como 50001, 50002). Los números de versión de las versiones α y β son un número más pequeño que el número de versión principal, por ejemplo, 19999.00071 significa α1 de la versión 20000 y 29999.50000 significa β2 de la versión 30000. Comenzando con 9001 en 2003, la última versión a partir de 2011 es 140000.
Urbit utiliza el método de control de versiones de Kelvin (llamado así por la escala de temperatura absoluta de Kelvin): las versiones de software comienzan en un número alto y cuentan hacia atrás hasta la versión 0, momento en el que el software se considera completo y no se realizan más cambios.
Números de versión interna
El software puede tener un número de versión de "construcción" que difiere del número de versión que se muestra en el nombre del producto (y generalmente sigue las reglas del número de versión de manera más consistente). Por ejemplo, Java SE 5.0 tiene un número de compilación de 1.5.0, mientras que las versiones de Windows que comienzan con NT 4 continúan usando la versión numerada estándar internamente: Windows 2000 es NT 5.0, XP es Windows NT 5.1, Windows Server 2003 y Windows XP Professional La edición x64 es NT 5.2, Windows Server 2008 y Vista es NT 6.0, Windows Server 2008 R2 y Windows 7 es NT 6.1, Windows Server 2012 y Windows 8 es NT 6.2, y Windows Server 2012 R2 y Windows 8.1 es NT 6.3, sin embargo, Windows La primera versión de 10 fue 10.0 (10.0.10240). Tenga en cuenta, sin embargo, que Windows NT ahora es solo la quinta revisión principal, ya que su primera versión tenía el número 3.1 (para coincidir con el número de versión de Windows en ese momento) y Windows 10 dio el salto de 6.3 a 10.0.
Versiones preliminares
Combinado con los diversos programas de lanzamiento enumerados anteriormente, es común usar un sistema para representar versiones preliminares que administra las diversas fases del ciclo de lanzamiento de software.
Los programas en sus primeras etapas a menudo se denominan software "alfa", después de la primera letra del alfabeto griego. Una vez que están maduros pero no están listos para su lanzamiento, pueden llamarse software "beta", llamado así por la segunda letra del alfabeto griego. Por lo general, el software alfa solo lo prueba el desarrollador, mientras que el software beta se distribuye para que lo pruebe la comunidad.
Algunos sistemas utilizan una versión numérica inferior a 1 (como 0,9) para indicar que están cerca de la versión final "1,0". Esta es una práctica común en el software de código abierto. Sin embargo, si la versión preliminar es un paquete existente (como la versión 2.5), se puede agregar una "a" o "alfa" al número de versión. Por lo tanto, una versión alfa de la versión 2.5 se puede identificar como 2.5a o 2.5.a.
Otro enfoque es referirse a las versiones previas al lanzamiento como "candidatos de lanzamiento", de modo que los paquetes que están a punto de lanzarse como un lanzamiento específico pueden tener "rc-#" después de esa etiqueta de lanzamiento, indicando un candidato El número de la versión; la etiqueta "rc" se elimina cuando se lanza la versión final.
soltar tren
Un tren de lanzamiento de software es una forma de programa de lanzamiento de software en el que diferentes series de software de versión para múltiples productos se lanzan regularmente como varios "trenes" diferentes. En general, para cada familia de productos, hay varios trenes de lanzamiento diferentes que se ejecutan en un momento dado, cada uno desde el lanzamiento inicial hasta el vencimiento final y la salida dentro de un marco de tiempo planificado. Los usuarios pueden experimentar con trenes de lanzamiento más nuevos antes de adoptarlos en producción, lo que les permite experimentar con lanzamientos "en bruto" más nuevos desde el principio, mientras continúan siguiendo los lanzamientos del tren anterior en su sistema de producción, y luego se ejecutan en trenes de lanzamiento más nuevos. entrenar a medida que madura.
La plataforma de software IOS de Cisco ha utilizado un programa de lanzamiento con muchos trenes diferentes a lo largo de los años. Recientemente, muchas otras plataformas han adoptado el modelo de tren de lanzamiento, incluidos Firefox y Fenix para Android, Eclipse, LibreOffice, Ubuntu, Fedora, Python, digiKam y VMware.
Algunos fabricantes han abandonado el número de versión principal (Dejando de lado el elemento más significativo)
Java de Sun también tiene a veces un sistema híbrido, el número de compilación siempre ha sido 1.x, pero solo x se menciona en el mercado:
JDK 1.0.3
JDK 1.1.2 a 1.1.8
J2SE 1.2.0 ("Java 2") a 1.4.2
Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 ("Java 5, 6, 7, 8").
Sun también dejó caer los primeros números para Solaris, con Solaris 2.8 (o 2.9) llamado Solaris 8 (o 9) en los materiales de marketing.
El conjunto de compilación PBX de código abierto de Asterisk dio un salto similar a principios de la década de 2010, y su líder de proyecto anunció que la versión actual 1.8.x pronto sería seguida por 10.
Muchos criticaron esta práctica porque rompía el significado semántico de las partes del número de versión, pero cada vez más proveedores la adoptaron, incluido Mozilla (para Firefox).
Versiones numeradas pares e impares
Entre las series 1.0 y 2.6.x, el kernel de Linux usó números de versión menores impares para versiones de desarrollo e incluso números de versión menores para versiones estables; consulte Linux Kernel § Numeración de versiones. Por ejemplo, Linux 2.3 es la serie de desarrollo del segundo diseño principal del kernel de Linux, mientras que Linux 2.4 es la serie de lanzamiento estable posterior a la madurez de Linux 2.3. Después del número de versión menor del 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 del kernel 2.6 en 2004, Linux ya no usa este sistema, sino que adopta un ciclo de lanzamiento más corto.
Otro software con ciclos de lanzamiento más largos usa el mismo sistema de paridad, como Node.js hasta la versión 0.12, así como GNOME y WineHQ.
Problemas de ordenación del número de versión (sistemas de ordenación del número de versión)
Los números de versión progresaron rápidamente de números enteros simples (1, 2, ...) a números racionales (2.08, 2.09, 2.10), y luego "números" no numéricos como 4: 3.4.3-2, por lo que estos números de versión complejos son se maneja mejor como cadenas. Los sistemas operativos que incluyen funciones de administración de paquetes (como todas las distribuciones de Linux o BSD no triviales) utilizarán un algoritmo específico de distribución para comparar los números de versión de diferentes paquetes. Por ejemplo, Red Hat y las distribuciones derivadas tienen un algoritmo de clasificación diferente al de una distribución similar a Debian.
Como ejemplo del comportamiento sorprendente de las implementaciones de ordenación de números de versión, en Debian, los ceros iniciales se ignoran, por lo que 5.0005 y 5.5 se consideran iguales y 5.5 < 5.0006. Esto puede confundir a los usuarios, es posible que las herramientas de coincidencia de cadenas no puedan encontrar un número de versión dado, y esto puede causar problemas 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 indican cada componente del esquema mayor.menor.versión con un ancho fijo. Perl representa su número de versión como un número de coma flotante; por ejemplo, la versión 5.8.7 de Perl también se puede representar como 5.008007. De esta forma, la versión teórica 5.8.10 se puede expresar como 5.008010. Otros paquetes empaquetan cada segmento en un ancho de bit fijo; por ejemplo, en Microsoft Windows, el número de versión 6.3.9600.16384 se puede representar como 0x0006000325804000 en hexadecimal. Si algún segmento del número de versión excede 999, el esquema de coma flotante fallará; el esquema de empaquetado binario que usa 16 bits por segmento fallará después de 65535.
Ejemplo de uso del número de versión en Python
Python Software Foundation publicó PEP 440 - Identificación de versión y especificación de dependencia, que describe su propio esquema flexible, que define un segmento de época, un segmento de lanzamiento, prelanzamiento y postlanzamiento y un segmento de lanzamiento de desarrollo.
Ejemplo de uso del número de versión TeX
TeX tiene un sistema especial de numeración de versiones, una característica inusual inventada por su desarrollador, Donald Knuth. A partir de la versión 3, las actualizaciones se indican agregando un dígito adicional al final para que el número de versión se acerque al número π; esta es una forma de numeración singular: un número de versión es el número de dígitos. La versión actual es 3.141592653. Esto refleja que TeX es muy estable y solo se esperan actualizaciones menores. El desarrollador de TeX, Donald Knuth, ha dicho que el último cambio absoluto será cambiar el número de versión a π, momento en el que todos los errores restantes se convertirán en características permanentes.
Del mismo modo, los números de versión de Metafont se aproximan asintóticamente al número e de Euler (2,72..., la base de los logaritmos naturales). El número de versión actual de Metafont es 2.71828182. Metafont también fue diseñado por Donald Knuth como complemento de su sistema de composición tipográfica TeX.
Ejemplo de uso del número de versión Apple Inc.
En los días clásicos de Mac OS, los números de versión menores rara vez se agregaban con ".1". Por lo tanto, "8.5" se comercializó como su propia versión, que significa "Mac OS 8.5", mientras que 8.6 en realidad significaba "8.5.1".
Mac OS X se desvió de esta tendencia, en gran parte porque "X" (el número romano para 10) apareció en el nombre del producto. Por lo tanto, todas las versiones de OS X comienzan 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 la 11.0. En su lugar, tiene el número 10.1, luego 10.2, 10.3 y así sucesivamente para cada versión principal posterior. Por lo tanto, la undécima versión principal de OS X está etiquetada 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. En un plan de lanzamiento basado en "X", el tercer número (en lugar del segundo) indica una versión secundaria y actualizaciones adicionales por debajo de ese nivel, así como actualizaciones importantes específicas de OS X después de que se lanza una nueva versión principal. Las actualizaciones de versión se denominan actualizaciones complementarias.
El número romano X se utiliza simultáneamente con fines de marketing en varias líneas de productos. Tanto QuickTime como Final Cut Pro saltaron directamente de la versión 7 a la versión 10, es decir, QuickTime X y Final Cut Pro X. Al igual que el propio Mac OS X, estos productos no son actualizaciones de versiones anteriores, sino programas completamente nuevos. Al igual que OS X, la versión principal de estos programas agrega un segundo dígito y la versión secundaria usa un tercer dígito. Con el lanzamiento de macOS 11.0, se eliminó la "X" en el nombre de Final Cut (ver más abajo), y la marca QuickTime dejó de tener sentido cuando el marco QuickTime quedó obsoleto a favor de AVFoundation en 2011 (reproducir El programa para video QuickTime se conoce solo como QuickTime Player desde su creación).
La próxima versión de macOS de Apple, tentativamente numerada 10.16, se anunció oficialmente como macOS 11 en la WWDC en junio de 2020 y se lanzó en noviembre de 2020. La próxima versión de macOS, macOS Monterey, se lanzará en octubre de 2021, aumentando su número de versión principal a 12.
Ejemplo de uso del número de versión Microsoft Windows
El sistema operativo Microsoft Windows utilizó inicialmente números de versión estándar para identificar 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 (versión 4.10) y Windows 2000 (versión 5.0), el año de lanzamiento se incluye en el nombre del producto. Después de Windows 2000, Microsoft creó la serie Windows Server, que continuó con el estilo basado en años, pero con una diferencia: para versiones menores, Microsoft agregó "R2" al título, por ejemplo, Windows Server 2008 R2 (versión 6.1). Este estilo se ha mantenido hasta ahora. Sin embargo, la versión de cliente de Windows no sigue un estilo consistente. Primero, recibieron nombres con sufijos alfanuméricos arbitrarios, como Windows Me (4.90), Windows XP (5.1) y Windows Vista (6.0). Por otra parte, Microsoft usó números incrementales en el título, pero esta vez no eran números de versión; Windows 7, Windows 8 y Windows 8.1 tenían números de versión 6.1, 6.2 y 6.3, respectivamente. En Windows 10, el número de versión saltó a 10.0, mientras que las actualizaciones posteriores del sistema operativo solo aumentaron el número de compilación y el número de revisión de compilación actualizada (UBR).
El sucesor de Windows 10, Windows 11, se lanzó el 5 de octubre de 2021. A pesar de ser llamado "11", la nueva versión de Windows no aumentó su número de versión principal a 11. En cambio, mantuvo el número de versión 10.0 utilizado por Windows 10.
El significado del número de versión de lanzamiento del software (Significado):
En las aplicaciones prácticas de la ingeniería de software, los consumidores o clientes utilizan los números de versión para identificar o comparar su copia de un producto de software con otra copia, como la última versión lanzada por el desarrollador. Para los programadores o las empresas, los números de versión generalmente cambian en función de la modificación continua del software, incluidos los componentes individuales del software, generalmente contenidos en un sistema de control de versiones.
Las estrategias de control de versiones de software son especialmente importantes para las bibliotecas y los marcos de software, pero también pueden ser muy útiles para las aplicaciones de línea de comandos (que pueden ser invocadas por otras aplicaciones) y, de hecho, cualquier otra aplicación (que puede ser creada o ampliada por terceros).
La gestión de versiones también es una práctica necesaria para implementar esquemas de parches y actualizaciones para muchos programas, especialmente para decidir automáticamente cómo actualizar.
El número de versión permite a quienes brindan soporte determinar exactamente qué código está ejecutando el usuario, para que puedan descartar errores que ya se han solucionado como la causa del problema y similares. Esto es especialmente importante cuando un programa tiene una gran base de usuarios, especialmente si la base es tan grande que las personas que brindan soporte técnico no son las personas que escribieron el código. La semántica de los números de estilo version.revision.change también es importante para los profesionales de la tecnología de la información, que a menudo la usan para determinar cuánta atención e investigación necesitan para dar una nueva versión antes de implementarla en sus instalaciones. Como regla general (una regla general), cuanto más cambia el número de versión, más probable es que haya un error (aunque revisar el registro de cambios puede revelar solo cambios superficiales o irrelevantes superficiales o irrelevantes). Esta es una de las razones de la repugnancia al enfoque de "eliminar la versión principal" adoptado por compañías como Asterisk: porque las personas tienen que (o al menos deberían) hacer pruebas de regresión exhaustivas para cada actualización.
Por ejemplo, si el software lanzado es una biblioteca pura, el uso de la comparación del número de versión puede indicar el nivel de compatibilidad (nivel de compatibilidad) y el impacto de la actualización.
Para correcciones de errores pequeños, se debe preservar el formato binario, el código fuente y la compatibilidad de serialización (una versión de corrección de errores debe preservar la compatibilidad binaria, de fuente y de serialización).
El cambio del número de versión secundaria tiene diferentes significados para diferentes proyectos, pero generalmente representa un hito en el código fuente, que puede considerarse como una incompatibilidad del código fuente.
Y los cambios de versión importantes, habrá cambios mayores, lo que significa que la compatibilidad de binario, fuente y serialización puede ser destruida.
Algunos programas vendidos pueden tener un período limitado de soporte posventa o pueden estar dentro de un rango de versión limitado. Por ejemplo, solo se admite el software con el mismo número de versión principal. Si es necesario aumentar el alcance del soporte, se requiere un nuevo contrato de venta.
Después de que el usuario compra el software, si el software necesita ser actualizado, de acuerdo con el contrato, también puede ser dentro de un tiempo limitado o dentro de un rango de versión limitado. Es decir, después de la compra del software, el servicio de seguimiento está relacionado con el cambio de versión, lo que afecta los derechos e intereses del usuario según el cambio de número de versión.
Después de que el producto se pone en el mercado, se pueden usar diferentes esquemas de versiones de marketing, es decir, cuanto mayor sea el número de versión, mejor, el número de versión más grande es mejor que el número de versión más pequeño, y es mejor que sea más grande que el número de versión de la competencia.
Por ejemplo, la versión del móvil de Apple es de nueva generación, es decir, se aumenta en uno el número de versión, lo que resulta muy cómodo de identificar. Cuanto mayor sea el número de versión, cuanto más nuevo, mejor. Por ejemplo, el iPhone 14 es mejor que el iPhone 13.
Además, cuando Apple diseña una nueva generación de teléfonos móviles, también intenta hacer distinciones en la apariencia para que los demás sepan que estás usando el último teléfono móvil, lo que estimula el deseo de comprar de las personas.
Más tarde, la definición de la versión de los teléfonos móviles Xiaomi también usó reglas similares, como los teléfonos móviles Xiaomi 13.
Además de la cantidad de información digital, hay algunos nombres especiales para distinguir las versiones con expresiones más amigables para los humanos. Por ejemplo, la versión de Max OS: de Cheetah (guepardo) a Ventura (nombre de una ciudad de California).
ver:
Descubre qué macOS está usando tu Mac - Soporte técnico de Apple
https://en.wikipedia.org/wiki/MacOS
Aplicación de la compilación del número de versión en campos que no son de software
En algunos sistemas de archivos, los archivos también tienen una versión numerada. El número de versión en el archivo es similar a la rutina utilizada en la ingeniería informática y de software. Cuando la estructura, el contenido o las condiciones cambian, el número de versión aumentará en 1. El número de versión que se agregará depende de la preferencia personal del autor y del tamaño o tamaño del cambio importancia.
===Línea de separación===
Algunos números de versión con significado político o cultural
Generalmente, la versión principal 0 indica la versión de desarrollo, lo que significa que el software está incompleto o no se puede usar de manera estable, y la versión en este momento puede no ser compatible con versiones anteriores. La versión 1.0 es un hito para el lanzamiento oficial, lo que indica que el software tiene al menos todas las características y funciones principales que los desarrolladores esperan implementar en esta versión, y se considera lo suficientemente confiable y se lanza con normalidad. Un buen ejemplo es el kernel de Linux, que se lanzó por primera vez como versión 0.01 en 1991 y no llegó a la versión 1.0.0 hasta 1994.
Los desarrolladores del emulador de juegos de arcade MAME no tienen la intención de lanzar una versión 1.0 del programa, porque siempre habrá más juegos de arcade para emular, por lo que el proyecto realmente no puede completarse. Entonces, a la versión 0.99 le sigue la versión 0.100.
Desde la omnipresencia de Internet, la mayoría de los proveedores de software comercial ya no siguen el adagio de que una versión importante debe estar completa, sino que confían en los parches con correcciones de errores para tratar los problemas que surgen, se han descubierto y tienen solución. .
Una práctica relativamente común, por razones de marketing, es dar saltos significativos en los números de versión. A veces, los proveedores de software eluden la versión 1.0 o lanzan rápidamente una versión con un número de versión posterior, porque muchos clientes creen que el software de la versión 1.0 es demasiado inmaduro para confiar en las implementaciones de producción. Por ejemplo, tomando como ejemplo dBase II, el número de versión cuando se lanzó este producto era II, y su número de versión significa que es más maduro.
Otras veces, el número de versión se aumenta para que coincida con la versión de un competidor. Esto se puede ver en muchos ejemplos de números de versión 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.
El número de versión de Microsoft también es un objetivo para que otros se pongan al día. El navegador Netscape saltó de la versión 5 a la versión 6, lo cual es consistente con el navegador IE de Microsoft, pero también se debe a que el conjunto de aplicaciones de Mozilla cambió su cadena de agente de usuario durante el proceso de desarrollo. antes de la 1.0, la versión 5 heredada y Netscape 6.x se basa en el código de Mozilla.
Otro ejemplo de mantenerse al día con la competencia es el salto de la versión 4 a la versión 7 de Slackware Linux en 1999.
Los números de versión a veces también están influenciados por supersticiones. El número de compilación de la versión 2007 de Microsoft Office es 12. La próxima versión, Office 2010, tiene la compilación 14 debido a la superstición que rodea al número 13. Visual Studio 2013 tiene un número de versión de producto de 12.0 y la versión más reciente de Visual Studio 2015 tiene un número de versión de 14.0 por el mismo motivo.
Roxio Toast pasa de la versión 12 a la versión 14, lo más probable es que se salte la superstición que rodea al número 13.
WordPerfect Office de Corel, la versión 13 se comercializa como "X3" (número romano 10 y "3"). Este proceso continuó hasta la siguiente versión, la X4. Lo mismo sucede con la suite de gráficos de Corel (es decir, CorelDRAW, Corel Photo-Paint) y su software de edición de video "Video Studio".
Sybase omitió las versiones principales 13 y 14 en su producto de base de datos relacional Adaptive Server Enterprise, pasando de 12.5 a 15.0.
Los diccionarios ABBYY Lingvo utilizan los números 12, x3 (14), x5 (15).
SUSE Linux Enterprise omitió las versiones 13 y 14 después de la versión 12 y lanzó SLES 15 directamente en julio de 2018.
También hay asignaciones de números de versión influenciadas por la cultura geek. La distribución de SUSE Linux, a partir de la versión 4.2, comienza con la referencia 42, la "Respuesta a la última pregunta sobre la vida, el universo y todo" mencionada en la Guía del autoestopista galáctico de Douglas Adams.
Una distribución de Slackware Linux con la versión 13.37, a la que hace referencia leet.
Finnix saltó de la versión 93.0 a la versión 100 en parte para cumplir con la afirmación de que "no habrá Finnix '95", una referencia a Windows 95.
===Línea de separación===
Hay tres tipos de liberaciones: mayores, menores y de emergencia.
lanzamiento de la versión principal
Los cambios importantes de versión generalmente anulan las versiones anteriores del software.
Una versión principal tiene una gran cantidad de cambios en el producto y mejoras clave en la funcionalidad. Por ejemplo, una versión importante podría incluir:
-
Reescritura de código para un mejor rendimiento y escalabilidad
-
Cambios en la interfaz de usuario para darle una nueva apariencia
-
Lanzamiento de nuevas características que cambian la forma en que usamos
-
Eliminar funciones obsoletas o en desuso
-
Proporciona nueva integración de software
-
Compatible con hardware nuevo
Los lanzamientos principales son los que más perturban a los usuarios. Introducen algo nuevo y pueden requerir tiempo y esfuerzo para descargar o configurar.
Esto significa que los lanzamientos principales pueden estar mal vistos y pueden requerir que brinde capacitación a sus clientes o dedique tiempo a migrar datos a la nueva versión.
También pueden indicar problemas o cambios de compatibilidad. Por ejemplo, es posible que las nuevas versiones principales no sean compatibles con versiones anteriores de hardware y programas más antiguos.
Por lo tanto, cuando esté a punto de lanzar una versión principal de un software, asegúrese de mantener informados a sus usuarios. No los sorprenda y asegúrese de estar listo para admitir nuevas versiones de su software.
Lanzamientos de versiones principales
Por lo general, anulan las versiones anteriores del software.
Un lanzamiento importante cuenta con cambios sustanciales en el producto y presenta mejoras clave en la funcionalidad. Por ejemplo, una versión principal podría incluir:
* Una base de código reescrita que ofrece mayor velocidad y resiliencia
* Cambios en la interfaz de usuario para una nueva apariencia
* Nuevos lanzamientos de funciones que cambian el juego
* La eliminación de funciones obsoletas o descartadas
* Integraciones en software nuevo y/o compatibilidad con hardware más nuevo
Qué significan los lanzamientos importantes para los usuarios
Los lanzamientos principales son los que más perturban a los usuarios. Introducen cosas nuevas y probablemente requieran tiempo y esfuerzo para descargar o configurar.
Esto significa que los lanzamientos importantes pueden causar aversión al cambio. Es posible que le soliciten que brinde capacitación a sus clientes o que dedique tiempo para migrar datos a la nueva versión.
También pueden significar problemas o cambios con la compatibilidad. Por ejemplo, es posible que una versión principal no sea compatible con hardware anterior y programas heredados.
Por lo tanto, cuando se esté preparando para un lanzamiento de software importante, asegúrese de mantener informados a sus usuarios. No los sorprenda y asegúrese de que está listo para admitirlos en la nueva versión de su software.
lanzamiento de la versión menor
Las versiones secundarias, también conocidas como actualizaciones, se instalan en función de las versiones principales. Es decir, modifican la versión actual del software.
Los lanzamientos menores son cambios más pequeños que los lanzamientos principales. No son una revisión completa o una nueva adición a su producto de software. En cambio, realzan y mejoran la funcionalidad existente.
Por lo tanto, una versión menor podría incluir:
-
Nuevas funciones y funciones limitadas
-
Actualizaciones menores a las características existentes
-
Corrección de errores menores y parches de seguridad continuos
Muchos software verificarán periódicamente si hay actualizaciones de versiones menores cuando se ejecutan, y algunos completarán las actualizaciones de versiones en segundo plano.
Los lanzamientos de versiones menores pueden causar algunas interrupciones para los usuarios. Pero tienen menos impacto que los principales lanzamientos.
Los lanzamientos de versiones menores son un acto de equilibrio para los usuarios de software. Necesita ejecutar una actualización de software para actualizar, pero después de la actualización no hace que el software se vea como algo nuevo.
Los usuarios siguen utilizando la versión actual del software, por lo que se necesita poco tiempo o esfuerzo para adaptarse a la última versión. También es mucho menos probable que los usuarios necesiten dedicar tiempo a aprender nuevas funciones.
Este tipo de lanzamiento de software aún puede significar que los usuarios enfrentan una ligera aversión al cambio. Por ejemplo, si se modificaron algunas opciones de la interfaz de usuario o si no les gustó una determinada función nueva.
Sin embargo, en la mayoría de los casos, los lanzamientos menores significan que no hay mucha interrupción en las mejoras de la experiencia.
Lanzamientos de versiones menores
Las versiones secundarias también se conocen como actualizaciones y se instalan sobre las versiones principales. Es decir, editan la versión actual del software.
Las versiones de software menores son más pequeñas que sus contrapartes principales. No son una revisión total ni una nueva versión de su oferta de software. Más bien, realzan y mejoran las funciones existentes.
Por lo tanto, un lanzamiento menor podría incluir:
* Nuevas funciones y funciones limitadas
* Pequeñas actualizaciones de las funciones existentes
* Corrección de errores menores y parches de seguridad continuos
Las versiones menores se ejecutarán con regularidad y, a menudo, lo harán en segundo plano.
Qué significan los lanzamientos menores para los usuarios
Los lanzamientos menores pueden representar alguna interrupción para los usuarios. Pero tienen menos impacto que los lanzamientos principales.
Los lanzamientos menores son un equilibrio para los usuarios de software. Pueden requerir el tiempo que lleva ejecutar la actualización, pero no representan cambios lo suficientemente grandes como para que el software parezca nuevo.
Los usuarios siguen utilizando la versión actual del software, por lo que se necesita poco o ningún esfuerzo para adaptarse a la última versión. También es mucho menos probable que los usuarios necesiten dedicar tiempo a aprender nuevas funciones.
Este tipo de versión de software aún puede significar que los usuarios se enfrentan a una pequeña aversión al cambio. Por ejemplo, si ha habido un ajuste en ciertas opciones de la interfaz de usuario o si no les gusta una nueva característica.
Sin embargo, en su mayor parte, los lanzamientos menores significan una experiencia mejorada para interrupciones menores.
Liberación de emergencia
Las versiones de emergencia también se conocen como "revisiones".
Las liberaciones de emergencia son para problemas repentinos o urgentes que deben solucionarse lo antes posible. Pueden resolver:
-
Errores críticos que impiden que partes del software funcionen
-
Una vulnerabilidad de seguridad de alta prioridad descubierta recientemente
El objetivo de las versiones de emergencia es que solucionan algunos problemas urgentes. No están destinados a mejorar en gran medida la experiencia del usuario, sino a garantizar que el software continúe funcionando de manera eficiente y segura.
Las versiones de emergencia solo tienen un efecto (visible) en los problemas que solucionan directamente. Por ejemplo, la característica X ya no falla o Y ya no es una violación de seguridad cibernética.
Los usuarios pueden haber experimentado inconvenientes o interrupciones relacionadas con errores o fallas. Su confianza en su servicio también puede haber disminuido. Por lo tanto, para los usuarios, un lanzamiento urgente significa que las cosas pueden volver a ser como antes o mantenerse en el buen camino.
Bueno, un lanzamiento de emergencia oportuno significa que los usuarios pueden continuar usando el software de manera efectiva. Y, si se hace de manera rápida y efectiva, puede restaurar la confianza del usuario en el producto.
Lanzamientos de software de emergencia
Es posible que también hayas oído hablar de ellos como "revisiones".
Los lanzamientos de emergencia están ahí para los momentos en que hay un problema repentino o apremiante que necesita solucionarse lo antes posible. Podrían abordar:
* Errores críticos que hacen que partes del software dejen de funcionar
* Una vulnerabilidad de seguridad de alta prioridad que se descubrió recientemente
El objetivo de los lanzamientos de emergencia es que solucionan algo urgente. No están allí para mejorar drásticamente la experiencia del usuario, sino para garantizar que el software continúe funcionando de manera efectiva y segura.
Qué significan los lanzamientos de emergencia para los usuarios
Los lanzamientos de emergencia solo afectan (notablemente) el problema que solucionan directamente. Por ejemplo, la característica X ya no falla o Y ya no representa un agujero de seguridad cibernética.
Los usuarios pueden haber experimentado inconvenientes o interrupciones debido al error o vulnerabilidad en cuestión. Su confianza en su servicio también puede haber disminuido. Por lo tanto, para los usuarios, los lanzamientos de emergencia significan que las cosas vuelven o se mantienen encaminadas.
Una rápida liberación de emergencia, entonces, significa que los usuarios pueden continuar usando el software de manera efectiva. Y, si se manejan de manera rápida y competente, también pueden restaurar la fe del producto perdido.
Resumir
Lanzamiento principal: una nueva actualización completa
Lanzamientos menores: actualizaciones pequeñas y periódicas
Lanzamientos de emergencia: revisiones repentinas y no planificadas
Y, ya sea que se trate de una nueva versión de su software o de una solución crítica para que siga funcionando, la versión de su software afectará a los usuarios.
Así que asegúrese de que estén preparados para los cambios que se avecinan.
Mayor: nuevas y radicales actualizaciones
Menor: actualizaciones pequeñas y periódicas
Emergencia: revisiones repentinas y no planificadas
Y ya sea que se trate de una nueva versión del software o de una solución crucial para que todo siga funcionando, los lanzamientos de su software tendrán un impacto en los usuarios.
Por lo tanto, asegúrese de que estén preparados para los cambios que se avecinan.
referencia:
1. Diferencias entre diferentes versiones de software
Los tres tipos de versiones de software y lo que significan para los usuarios - Parker Software
2. Descripción del número de versión
3. Descripción del número de versión de Wiki
https://en.wikipedia.org/wiki/Software_versioning
Otras lecturas:
Una nota sobre los números de versión y la compatibilidad
https://medium.com/fiverr-engineering/major-minor-patch-a5298e2e1798