¿Qué representan típicamente los números en una versión (es decir, v1.9.0.1)?

Tal vez esta es una pregunta tonta, pero siempre he asumido que cada número delineado por un punto representa un componente único del software. Si eso es cierto, ¿alguna vez representan algo diferente? Me gustaría comenzar a asignar versiones a las diferentes compilaciones de mi software, pero no estoy realmente seguro de cómo debería estructurarse. Mi software tiene cinco componentes distintos.

En la versión 1.9.0.1 :

• 1 : Revisión importante (nueva interfaz de usuario, muchas características nuevas, cambio conceptual, etc.)

• 9 : Revisión menor (tal vez un cambio en un cuadro de búsqueda, 1 característica agregada, colección de correcciones de errores)

• 0 : lanzamiento de corrección de errores

• 1 : Número de compilación (si se usa), es por eso que ve .NET Framework usando algo como 2.0.4.2709

No encontrarás muchas aplicaciones que se reducen a cuatro niveles, 3 generalmente es suficiente.

Existe la especificación de versiones semánticas

Este es el resumen de la versión 2.0.0:

Dado un número de versión MAJOR.MINOR.PATCH, incremente el:

1. Versión PRINCIPAL cuando realiza cambios de API incompatibles,
2. Versión MENOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y
3. Versión PATCH cuando realiza correcciones de errores compatibles con versiones anteriores.

Las etiquetas adicionales para los metadatos previos al lanzamiento y de compilación están disponibles como extensiones del formato MAJOR.MINOR.PATCH.

Puede ser muy arbitrario y difiere de un producto a otro. Por ejemplo, con la distribución de Ubuntu, 8.04 se refiere a 2008. Abril

Por lo general, los números más grandes (principales) de la izquierda indican una versión principal, y cuanto más avanza hacia la derecha, menor es el cambio involucrado.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Cuantos más puntos, menor será el lanzamiento. No hay un estándar sólido real más allá de eso: puede significar cosas diferentes según lo que decidan los encargados del proyecto.

WordPress, por ejemplo, sigue estas líneas:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 a 2.0 sería una gran versión: características, cambios de interfaz, cambios importantes en las API, rotura de algunas plantillas y complementos 1.6, etc. 2.0 a 2.0.1 sería una versión menor, tal vez reparando un error de seguridad. 2.0.2 a 2.1 sería una versión importante: nuevas características, en general.

Los números pueden ser útiles como se describe en otras respuestas, pero considere cómo también pueden no tener sentido ... Sun, ya sabes SUN, java: 1.2, 1.3, 1.4 1.5 o 5 y luego 6. En la versión anterior de Apple II, los números significaban Alguna cosa. Hoy en día, la gente está renunciando a los números de versión y va con nombres tontos como "Feisty fig" (o algo así) y "hardy heron" y "europa" y "ganymede". Por supuesto, esto es mucho menos útil porque te quedarás sin lunas de júpiter antes de dejar de cambiar el programa, y ​​dado que no hay un orden obvio, no puedes saber cuál es más nuevo.

En la versión v1.9.0.1: este es el esquema de control de versiones explícito que se utiliza cuando no desea utilizar el nombre para las versiones preliminares o compilar como -alpha, -beta.

1: versión principal que puede romper la compatibilidad con versiones anteriores

9: Agregar nuevas funciones para apoyar su aplicación junto con compatibilidad con versiones anteriores.

0: algunas correcciones de errores menores

1: Número de compilación (número de prelanzamiento)

pero hoy en día, no encontrará dicho esquema de versiones. Consulte Versiones semánticas [semver2.0] https://semver.org/

Los números de versión generalmente no representan componentes separados. Para algunas personas / software, los números son bastante arbitrarios. Para otros, las diferentes partes de la cadena del número de versión representan cosas diferentes. Por ejemplo, algunos sistemas aumentan partes del número de versión cuando cambia un formato de archivo. Entonces, V 1.2.1 es un formato de archivo compatible con todas las demás versiones de V 1.2 (1.2.2, 1.2.3, etc.) pero no con V 1.3. En última instancia, depende de usted qué esquema desea utilizar.

Usualmente es:

MajorVersion.MinorVersion.Revision.Build

Depende, pero la representación típica es la de major.minor.release.build .

Dónde:

• major es la versión de lanzamiento principal de su software, piense en .NET 3.x
• menor es la versión de lanzamiento menor de su software, piense en .NET x.5
• lanzamiento es el lanzamiento de esa versión, generalmente las correcciones de errores incrementarán esto
• build es un número que denota el número de compilaciones que ha realizado.

Entonces, por ejemplo, 1.9.0.1, significa que es la versión 1.9 de su software, después de 1.8 y 1.7, etc., donde 1.7, 1.8 y 1.9 de alguna manera típicamente agregan pequeñas cantidades de nuevas características junto con correcciones de errores. Como es xx0.x, es la versión inicial de 1.9, y es la primera versión de esa versión.

También puede encontrar buena información en el artículo de Wikipedia sobre el tema .

Major.Minor.Bugs

(O alguna variación sobre eso)

Los errores suelen ser correcciones de errores sin una nueva funcionalidad.

Menor es un cambio que agrega nueva funcionalidad pero no cambia el programa de ninguna manera importante.

Major es un cambio en el programa que rompe la funcionalidad anterior o es tan grande que de alguna manera cambia la forma en que los usuarios deberían usar el programa.

Todos eligen lo que quieren hacer con estos números. He tenido la tentación de llamar lanzamientos abc ya que es bastante tonto de todos modos. Dicho esto, lo que he visto en los últimos 25 años de desarrollo tiende a funcionar de esta manera. Digamos que su número de versión es 1.2.3.

El "1" indica una revisión "mayor". Por lo general, esta es una versión inicial, un gran cambio en el conjunto de características o una reescritura de partes significativas del código. Una vez que se determina el conjunto de características y se implementa al menos parcialmente, pasa al siguiente número.

El "2" indica un lanzamiento dentro de una serie. A menudo usamos esta posición para ponernos al día con las características que no llegaron a la última versión principal. Esta posición (2) casi siempre indica un agregado de características, generalmente con correcciones de errores.

El "3" en la mayoría de las tiendas indica un lanzamiento de parche / corrección de errores. Casi nunca, al menos en el aspecto comercial, esto indica un agregado significativo de características. Si las características aparecen en la posición 3, probablemente sea porque alguien registró algo antes de que supiéramos que teníamos que hacer una versión de corrección de errores.

¿Más allá de la posición "3"? No tengo idea de por qué la gente hace ese tipo de cosas, simplemente se vuelve más confuso.

Cabe destacar que algunos de los OSS por ahí arrojan todo esto fuera de control. Por ejemplo, la versión 10 de Trac es en realidad 0.10.XX Creo que muchas personas en el mundo de OSS carecen de confianza o simplemente no quieren anunciar que han hecho un lanzamiento importante.

Desde el archivo C # AssemblyInfo.cs puede ver lo siguiente:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision sería mi suposición.
Pero puede variar mucho entre productos.

Mayor.minor.punto.construcción generalmente. Mayor y menor se explican por sí mismos, el punto es una versión para algunas correcciones de errores menores, y la compilación es solo un identificador de compilación.

Sip. Las versiones principales agregan nuevas características grandes, pueden romper la compatibilidad o tener dependencias significativamente diferentes, etc.

Las versiones menores también agregan funciones, pero son versiones más pequeñas, a veces simplificadas y portadas de la versión beta principal.

Si hay un tercer componente de número de versión, generalmente es para correcciones de errores importantes y correcciones de seguridad. Si hay más, realmente depende tanto del producto que es difícil dar una respuesta general.

Creo que el paradigma de la solución principal release.minor release.bug es bastante común.

En algunos contratos de soporte empresarial hay $$$ (o incumplimiento de responsabilidad contractual) asociado con la forma en que se designa un lanzamiento en particular. Un contrato, por ejemplo, podría otorgarle al cliente cierto número de lanzamientos importantes en un período de tiempo, o prometer que habrá menos de x número de lanzamientos menores en un período, o que el soporte continuará estando disponible para tantos lanzamientos. Por supuesto, no importa cuántas palabras se pongan en el contrato para explicar qué es una versión principal versus una versión menor, siempre es subjetiva y siempre habrá áreas grises, lo que lleva a la posibilidad de que el proveedor de software pueda jugar con el sistema. batir tales disposiciones contractuales.

Las personas no siempre reconocen la sutil diferencia entre los números de versión como 2.1, 2.0.1 o 2.10: pregúntele a una persona de soporte técnico cuántas veces han tenido problemas con esto. Los desarrolladores están orientados a los detalles y están familiarizados con las estructuras jerárquicas, por lo que este es un punto ciego para nosotros.

Si es posible, exponga un número de versión más simple a sus clientes.

En el caso de una biblioteca, el número de versión le informa sobre el nivel de compatibilidad entre dos versiones y, por lo tanto, lo difícil que será una actualización.

Una versión de corrección de errores necesita preservar la compatibilidad binaria, de origen y de serialización.

Los lanzamientos menores significan diferentes cosas para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de origen.

Los números de versiones principales pueden romper las tres formas.

Escribí más sobre la justificación aquí .

Una combinación de mayor, menor, parche, compilación, parche de seguridad, etc.

Los dos primeros son mayores y menores; el resto dependerá del proyecto, la empresa y, a veces, la comunidad. En sistemas operativos como FreeBSD, tendrá 1.9.0.1_number para representar un parche de seguridad.

Depende un poco del lenguaje, Delphi y C #, por ejemplo, tienen diferentes significados.

Por lo general, los dos primeros números representan una versión mayor y una menor, es decir, 1.0 para la primera versión real, 1.1 para algunas correcciones de errores importantes y nuevas características menores, 2.0 para una nueva versión de gran característica.

El tercer número puede referirse a una versión o revisión "realmente menor". 1.0.1 es solo una pequeña corrección de errores a 1.0.0, por ejemplo. Pero también puede llevar el número de Revisión de su Sistema de Control de Fuente, o un número cada vez mayor que se incrementa con cada compilación. O un sello de fecha.

Un poco más de detalle aquí . "oficialmente", en .net, los 4 números son "Major.Minor.Build.Revision", mientras que en Delphi hay "Major.Minor.Release.Build". Yo uso "Major.Minor.ReallyMinor.SubversionRev" para mis versiones.

Generalmente, los números están en el formato version.major.minor.hotfix, no en componentes internos individuales. Entonces, v1.9.0.1 sería la versión 1, versión principal 9 (de v1), versión menor (de v1.9) 0, hotfix 1 de (v1.9.0).

El primer número generalmente se conoce como el número de versión principal. Básicamente se usa para denotar cambios significativos entre compilaciones (es decir, cuando agrega muchas características nuevas, incrementa la versión principal). Los componentes con diferentes versiones principales del mismo producto probablemente no sean compatibles.

El siguiente número es el número de versión menor. Puede representar algunas características nuevas, o una serie de correcciones de errores o pequeños cambios de arquitectura. Los componentes del mismo producto que difieren en el número de versión menor pueden o no funcionar juntos y probablemente no deberían.

El siguiente generalmente se llama número de compilación. Esto puede incrementarse diariamente, o con cada compilación "lanzada", o con cada compilación. Puede haber solo pequeñas diferencias entre dos componentes que difieren solo por el número de compilación y, por lo general, pueden funcionar bien juntos.

El número final suele ser el número de revisión. Muchas veces esto es usado por un proceso de compilación automático, o cuando estás haciendo compilaciones "desechables" para probar.

Cuando incrementa sus números de versión es de usted, pero siempre debe incremento o permanecer igual . Puede hacer que todos los componentes compartan el mismo número de versión o que solo incrementen el número de versión en los componentes modificados.

El número de versión de una pieza compleja de software representa el paquete completo y es independiente de los números de versión de las partes. La versión 3.2.5 de Gizmo podría contener Foo versión 1.2.0 y Bar versión 9.5.4.

Al crear números de versión, úselos de la siguiente manera:

1. El primer número es el lanzamiento principal. Si realiza cambios significativos en la interfaz de usuario o necesita romper las interfaces existentes (para que sus usuarios tengan que cambiar su código de interfaz), debe ir a la nueva versión principal.

2. El segundo número debe indicar que se han agregado nuevas características o que algo funciona de manera diferente internamente. (Por ejemplo, la base de datos Oracle podría decidir usar una estrategia diferente para recuperar datos, haciendo que la mayoría de las cosas sean más rápidas y algunas más lentas). Las interfaces existentes deberían seguir funcionando y la interfaz de usuario debería ser reconocible.

3. La numeración de versiones depende de la persona que escribe el software: Oracle utiliza cinco (!) Grupos, es decir. una versión de Oracle es algo así como 10.1.3.0.5. Desde el tercer grupo hacia abajo, solo debe introducir correcciones de errores o cambios menores en la funcionalidad.

los que varían menos serían los dos primeros, para major.minor, después de eso puede ser cualquier cosa, desde compilación, revisión, lanzamiento, hasta cualquier algoritmo personalizado (como en algunos productos de MS)

Cada organización / grupo tiene su propio estándar. Lo importante es que se adhiera a la notación que elija, de lo contrario, sus clientes se confundirán. Habiendo dicho eso, usé normalmente 3 números:

x.yz.bbbbb. Donde: x: es la versión principal (nuevas características principales) y: es el número de versión menor (nuevas características pequeñas, pequeñas mejoras sin cambios en la interfaz de usuario) z: es el paquete de servicio (básicamente lo mismo que xy pero con algunas correcciones de errores bbbb: es el número de compilación y solo es realmente visible desde el "cuadro sobre" con otros detalles para atención al cliente. bbbb es un formato libre y cada producto puede usarlo.

Esto es lo que usamos:

1. Primer número = Era general del sistema. Cambia cada dos años y generalmente representa un cambio fundamental en la tecnología, en las características del cliente o en ambas.
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 el primer número cambia.
3. Tercer número = cambio de software solamente. Esto generalmente se puede implementar cliente por cliente, ya que el esquema de la base de datos no cambia. Se restablece a cero si cambia el segundo número.
4. Número de versión de Subversion. Rellenamos esto automáticamente en la compilación utilizando la herramienta TortoiseSVN. Este número nunca se restablece, sino que se incrementa continuamente. Con 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 lidiar con la pregunta de número mayor / número menor (cuán grande es el cambio) 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!

versión: v1.9.0.1

dónde-

. v es la abreviatura de la versión. Varía de una compañía a otra dependiendo de la nomenclatura adoptada en su organización. Puede silenciar en alguna organización como 1.9.0.1

. 1 indica la versión principal, se actualizará en la modificación arquitectónica en pilas de aplicaciones, infraestructura (plataforma) o interfaz de redes expuestas

. 9 incates menores, se actualizarán en la actividad como agregar nuevos componentes como ui, api, base de datos, etc. bajo una arquitectura específica

. 0 indica característica, se actualizará en cualquier mejora en los componentes existentes (ui, api, base de datos, etc.)

. 1 indica el contador de compilación en todas las fases mayor, menor y característica. También incluye revisiones después de la publicación de producción.