¿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 asumí que cada número delineado por un período representaba un solo componente del software. Si eso es verdad, ¿alguna vez representan algo diferente? Me gustaría comenzar a asignar versiones a las diferentes versiones de mi software, pero no estoy realmente seguro de cómo debería estar estructurado. Mi software tiene cinco componentes distintos.
En la versión 1.9.0.1 :
1 : Revisión mayor (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 : Liberación de corrección de errores
1 : Número de compilación (si se usa): es por eso que ve el marco .NET usando algo como 2.0.4.2709
No encontrarás muchas aplicaciones que bajen a cuatro niveles, 3 suele ser suficiente.
Hay la especificación de versión semántica
Este es el resumen de la versión 2.0:
Dado un número de versión MAJOR.MINOR.PATCH, incremente el:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.Las etiquetas adicionales para los metadatos de prelanzamiento y 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 a la izquierda (principales) indican un lanzamiento importante, y cuanto más se vaya hacia la derecha, menor será el cambio.
major.minor [.maintenance [.build]]
Los números pueden ser útiles como lo describen otras respuestas, pero considere cómo también pueden carecer de significado ... Sun, ya sabe Sun, Java: 1.2, 1.3, 1.4 1.5 o 5 y luego 6. En los viejos números de versión de Apple II significados Alguna cosa. Hoy en día, la gente se da por vencida con los números de versión y va con nombres estúpidos como "Higo feisty" (o algo así) y "Heron Hardy" y "Europa" y "Ganimedes". Por supuesto, esto es mucho menos útil porque, se te acabarán las lunas de Júpiter antes de que dejes de cambiar el programa y, como no hay un pedido obvio, no puedes saber cuál es el más nuevo.
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 ...
La versión 1.6 a 2.0 sería una gran versión: características, cambios en la interfaz, cambios importantes en las API, ruptura de algunas plantillas y complementos 1.6, etc. 2.0 a 2.0.1 sería una versión menor, tal vez solucionando 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 significar cualquier cosa que desee, aunque generalmente no están relacionados con componentes individuales, sino con cambios mayores contra menores en el mantenimiento de su versión.
Echa un vistazo a estos recursos:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
Aclamaciones
Los números de versión no suelen representar 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 el formato de un archivo. Así que 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.
Desde el archivo AssemblyInfo.cs de C # 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 conjetura.
Pero puede variar mucho entre productos.
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 .NET 3.x
- menor es la versión de lanzamiento menor de su software, piense .NET x.5
- release es el lanzamiento de esa versión, por lo general las correcciones de errores incrementarán esto
- build es un número que denota el número de construcciones que ha realizado.
Entonces, por ejemplo, 1.9.0.1, significa que es la versión 1.9 de su software, que sigue a 1.8 y 1.7, etc. donde 1.7, 1.8 y 1.9, de alguna manera, por lo general, agrega pequeñas cantidades de nuevas funciones junto con las correcciones de errores. Dado que es x.x.0.x, es la versión inicial de 1.9, y es la primera compilación de esa versión.
También puede encontrar buena información en el artículo Wikipedia sobre el tema .
Major.Minor.Bugs
(O alguna variación sobre eso)
Los errores suelen ser correcciones de errores sin nuevas funcionalidades.
Menor es un cambio que agrega una nueva funcionalidad pero no cambia el programa de ninguna manera importante.
Importante 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 deben usar el programa.
Todos eligen lo que quieren hacer con estos números. He tenido la tentación de llamar a releases a.b.c ya que de todos modos es bastante tonto. 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, se trata de una versión inicial, un gran cambio de conjunto de características o una reescritura de partes significativas del código. Una vez que se determina el conjunto de características y, al menos, se implementa parcialmente, se 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 se lograron en 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 parche/corrección de errores. Casi nunca, al menos en el lado comercial, esto indica una característica significativa agregada. Si las funciones aparecen en la posición 3, entonces probablemente se deba a que alguien verificó 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 ni idea de por qué la gente hace ese tipo de cosas, simplemente se vuelve más confuso.
En particular, 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.X.X. Creo que muchas personas en el mundo de OSS o bien carecen de confianza o simplemente no quieren anunciar que tienen un gran lanzamiento hecho.
Las personas no siempre reconocen la diferencia sutil entre los números de versión como 2.1, 2.0.1 o 2.10; pregunte a una persona de soporte técnico cuántas veces han tenido problemas con esto. Los desarrolladores están orientados a los detalles y 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.
El paradigma de la versión principal de release.minor release.bug es bastante común, creo.
En algunos contratos de soporte a la empresa, hay $$$ (o incumplimiento de la obligación del contrato) asociada con la forma en que se designa una liberación en particular. Un contrato, por ejemplo, puede dar derecho a un cliente a 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á disponible para tantos lanzamientos Por supuesto, no importa cuántas palabras se incluyan en el contrato para explicar qué es un lanzamiento importante frente a un lanzamiento menor, siempre es subjetivo y siempre habrá áreas grises, lo que lleva a la posibilidad de que el proveedor de software pueda jugar con el sistema vencer dichas disposiciones contractuales.
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, qué tan difícil será una actualización.
Una versión de corrección de errores debe conservar la compatibilidad binaria, de origen y de serialización.
Las versiones menores significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de la fuente.
Los principales números de versión pueden romper las tres formas.
Escribí más sobre la justificación aquí .
En la versión v1.9.0.1: Este es el esquema de control de versiones explícito usado cuando no desea usar el nombre para las versiones previas o compilación como -alpha, -beta.
1: Versión principal que podría romper la compatibilidad hacia atrás
9: Adición de nuevas características para apoyar su aplicación junto con la 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. No haga referencia a las versiones semánticas [semver2.0] https://semver.org/
Major.minor.point.build generalmente. Mayor y menor son autoexplicativos, punto es un lanzamiento para algunas correcciones de errores menores, y la compilación es solo un identificador de compilación.
Por lo general es
MajorVersion.MinorVersion.Revision.Build
Sip. Las versiones principales agregan funciones nuevas e importantes, pueden romper la compatibilidad o tener dependencias significativamente diferentes, etc.
Las versiones secundarias también agregan funciones, pero son versiones más pequeñas y, en ocasiones, simplificadas, de la versión beta principal.
Si hay un tercer componente de número de versión, generalmente se trata de 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.
El primer número se conoce normalmente 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 en la 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 se suele llamar el número de compilación. Esto puede incrementarse diariamente, o con cada compilación "liberada", o con cada compilación en absoluto. Es posible que solo existan pequeñas diferencias entre dos componentes que difieren solo en 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 se usa en un proceso de compilación automática o cuando se realizan compilaciones desechables "únicas" para realizar pruebas.
Cuando incrementa sus números de versión, depende de usted, pero siempre deben incrementar o permanecer igual . Puede hacer que todos los componentes compartan el mismo número de versión, o solo incrementar 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 puede contener la versión 1.2.0 de Foo y la versión 9.5.4 de Bar.
Al crear números de versión, utilícelos de la siguiente manera:
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 los usuarios tengan que cambiar su código de interfaz), debe ir a la nueva versión principal.
El segundo número debe indicar que se han agregado nuevas funciones o que algo funciona de manera diferente internamente. (Por ejemplo, la base de datos Oracle puede decidir usar una estrategia diferente para recuperar datos, lo que hace que la mayoría de las cosas sean más rápidas y algunas más lentas). Las interfaces existentes deben seguir funcionando y la interfaz de usuario debe ser reconocible.
La numeración de la versión 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 primeros dos, para major.minor, después de eso puede ser cualquier cosa, desde compilación, revisión, lanzamiento, hasta algoritmos personalizados (como en algunos productos de MS)
Esto es lo que usamos:
- Primer número = la era general del sistema. Cambia cada dos años y generalmente representa un cambio fundamental en la tecnología, las características del cliente o ambas.
- 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, por lo que cambiar la estructura de la base de datos requiere un proceso de actualización cuidadoso). Se restablece en 0 si el primer número cambia.
- Tercer número = solo cambio de software. Por lo general, esto puede implementarse cliente por cliente, ya que el esquema de la base de datos no se modifica. Se restablece a cero si el segundo número cambia.
- 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. 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 lidiar con la pregunta del número mayor/número menor (qué tan importante es un cambio importante) y no veo el beneficio de eso. Si no necesita hacer 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!
Cada organización/grupo tiene su propio estándar. Lo importante es que se apegue a la notación que elija, de lo contrario, sus clientes se confundirán. Habiendo dicho que he usado 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 (pequeñas características nuevas, pequeñas mejoras sin cambios en la interfaz de usuario) z: es el paquete de servicio (básicamente el 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 "about" con otros detalles para el soporte al cliente. bbbb es un formato gratuito y cada producto puede usarlo por sí mismo.
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 idioma, Delphi y C #, por ejemplo, tienen diferentes significados.
Por lo general, los dos primeros números representan una versión principal y una versión menor, es decir, 1.0 para la primera versión real, 1.1 para algunas correcciones de errores importantes y nuevas funciones secundarias, 2.0 para una nueva versión de características.
El tercer número puede referirse a una versión "realmente menor", o revisión. 1.0.1 es solo una corrección de errores muy pequeña a 1.0.0 por ejemplo. Pero también puede llevar el número de Revisión de su sistema de control de origen, o un número cada vez mayor que se incrementa con cada compilación. O una marca de datos.
Un poco más de detalle aquí . "official", 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 mi versionado.
Generalmente, los números están en el formato de version.major.minor.hotfix, no componentes internos individuales. Entonces v1.9.0.1 sería la versión 1, versión principal 9 (de v1), versión secundaria (de v1.9) 0, corrección 1 de (v1.9.0).