¿Puedo obtener algunos consejos de numeración de versiones?

Question

Nuestro producto tiene una larga historia (12 años más o menos).

Sus orígenes están en VB3 (Versión 1) y más tarde VB6 (Versión 2). (Los números de versión eran un "desayuno de perros" y el control de versiones era una pesadilla.

He estado involucrado aquí durante un par de años. Tenemos la versión 3 en desarrollo en la plataforma .Net pero la versión 2 sigue siendo admitido con versiones periódicas: alrededor de 3 o 4 por año.

Introduje construcciones automáticas nocturnas cuando comencé y el número de versión de nuestro producto era 2.2.2. Todo el mundo planeaba lanzar 2.2.3, pero el sistema automatizado proceso de compilación y el "interesante" sistema de numeración de 3 partes de VB6, significa que necesitamos hacer uso de la tercera porción - número de compilación/revisión - que se supone que es.

Así que lanzamos versi en 2.3 (con un número de compilación de "lo que sea") y se puso a trabajar en 2.4 (incrementando los números de compilación cada noche), luego 2.5, luego 2.6 etc.

El número de compilación estaba oculto a la vista pública pero disponible para soporte a pesar de que rara vez lanzamos más de una compilación de una versión, sin embargo, hemos necesitado parchear ocasionalmente.

Consistencia garantizada. Ahora llegamos a 2.9. Estamos a punto de pasar a 2.10 (dos punto nueve, hasta dos punto diez). Lamentablemente, los chicos no técnicos están leyendo esto como un número racional (dos puntos uno). No pueden entender por qué no nos limitamos a ir a la Versión 3.0, como contar. (El número de compilación solo se muestra en la pantalla "Ayuda/Acerca de" para fines de soporte).

No creo que se justifique una actualización del producto (número principal) especialmente debido a las expectativas que esto establecerá en el mercado.

¿Hay una manera correcta de proceder aquí? (2.10 o 3.0 o algo mejor, ¿o incluso importa?)

(NB. He hecho todo lo posible para garantizar que el número de versión ahora se muestre como 2.09, en lugar de 2.9 (en nuestro sitio web, pantalla de bienvenida del producto y varios otros lugares públicos, etc.), de modo que cuando pasamos a 2.10 puede tener más sentido, pero esto es potencialmente tan confuso porque 2.09 es realmente un número racional inferior a 2.8 ...)

Ver también:

Deciding on version numbers

How to do version numbers?

How do you know what version number to use?

Answer 1

Mírelo como una oportunidad para que los chicos no técnicos aprendan algo ;-) Los números de versión deben ser como números de capítulos y secciones en un libro, dividen la vida de su programa en bloques coherentes e internamente consistentes.

Answer 2

Usted podría hacer o incluso 2.9.1 2.10.1, pero hay muchos proyectos que mantienen a contar. 2.10, 2.11 12 13 etc.

Answer 3

¿Cómo versionas tu propio software? Depende de ti. No hay "correcto" o "incorrecto", aparte de lo mejor después de considerar puntos de vista de mantenimiento, gestión de lanzamientos y soporte al cliente. Lo importante es que controle el control de versiones, que lo comprenda, que todos los que trabajan con el producto lo comprendan y que no cause problemas más adelante. No tiene sentido pasar de 2.9 a 2.10 en lugar de 3.0, excepto el significado que le da .

Answer 4

Creo que siguió el enfoque correcto yendo hacia 2.10.El objetivo principal de los números de versión debe ser la agrupación de nuevas características y el desarrollo en versiones liberables definibles. Si su numeración se interpone en este camino, necesita un esquema de numeración diferente.

Answer 5

Si 2.10 causa confusión, sáltelo y vaya a 2.11. Prepárese para el mismo problema con 2.20 aunque :)

Answer 6

Sugeriría utilizar siempre al menos 3 componentes en sus números de versión, y no ocultar nada más que el cuarto o más componentes. Siga esa convención en todas partes, porque hace obvio para las personas no técnicas que no puede ser un número racional, tiene que ser algo más (es decir, un compuesto de tres enteros).

• 2.8.0
• 2.9.0
• 2.10.0
• 2.11.0
• ...

Además, en aproximadamente diálogos, se adhieren a la fecha de construcción (aaaa-mm-dd) cerca del numero de version. Si el cliente se confunde con los números de versión, puede simplemente comparar las fechas, es decir, más más intuitivo para personas normales.

Answer 7

Recomiendo desacoplar su versión de marketing de las versiones internas de sus archivos DLL y otras cosas. Tienen una semántica diferente.

Answer 8

Wikipedia tiene very good article on software versioning

Si está trabajando en el largo proyecto en curso, identificadores basados ​​en la secuencia (como 1.0, 2.0, etc.) no lo hacen escala.

Personalmente me gusta (y prefiero) el esquema de versiones de Ubuntu que está utilizando el año y el mes de lanzamiento en su versión. Ubuntu 8.04, por ejemplo, fue lanzado en abril de 2008.

Answer 9

Gracias - hay tantas buenas respuestas aquí.

Estoy teniendo "aceptar una ansiedad de respuesta" - pero creo que es probable que tome un poco de cada respuesta.

En primer lugar, no es correcto o incorrecto aquí. En segundo lugar, la numeración no debería interferir con nada.

La numeración de versiones se puede considerar como capítulos y números de sección en un libro, lo que realmente me ayudará a explicar a los demás, por lo menos en lo que estoy pensando.

Separar/desacoplar las versiones de marketing de la numeración de versiones técnicas/de desarrollo lo resolvería todo ... aunque esta es una respuesta a más largo plazo.

me quedo con 2,10 a seguir 2,9 - y voy a la batalla en ... y definitivamente investigar Ubuntu

Answer 10

Las otras respuestas son sólo la mitad derecha. Los números de versión tienen el significado que les da, pero también tienen el significado que otros les dan. Tu propio significado realmente no importa ya que no estarás allí para corregir a tus usuarios. Si piensan que va de 2.9 a 3.0 es un gran salto, entonces así es como lo tomarán. Si tienen miedo de usar versiones x.0, entonces no lo harán. Si están acostumbrados a que los lanzamientos numerados impares sean alfas, entonces no los usarán.

Por mucho que me gustaría decirlo, los números de versión son una herramienta de marketing. Le dicen algo al usuario sobre el lanzamiento, por lo que debe tenerlo en cuenta al elegir sus números de versión.

El problema es que los números de versión significan cosas diferentes para diferentes personas. Hay algunas cosas que puedes predecir Como mencioné anteriormente, las personas serán sospechosas de x.0 versiones. Esperarán grandes cambios para 2.x a 3.x. Si quieres jugar, ven, adelante.

Hay dos atributos esenciales de los números de versión. Primero, siempre deben subir. Segundo, deben clasificarse fácilmente. El primero es obvio, pero el segundo es a menudo violado. Considere la versión 2.9 -> 2.10. En términos numéricos, 2.9 es mayor que 2.10. Debe considerarlos números de versión mayor/menor para que se ordenen correctamente. De esto surge la confusión sobre si 2.10 o 3.0 siguen 2.9. Incluso si conocemos las reglas de clasificación, todavía parece estar mal. Por esta razón, siempre relleno mis versiones. 2.09 es seguido por 2.10. Ordena correctamente tanto como un número como un par de puntos.

Eso todavía nos deja con el usuario tratando de adivinar el significado del número de versión, como los numerólogos cerniéndose a través de los números ganadores de la lotería. Puedes intentar jugar ese juego, o puedes dejarlo. ¿Por qué usar un par de puntos en absoluto? Usa un entero. No es ambiguo. Se clasifica trivialmente. No da ningún significado falso para que el usuario se prenda.

Puedo ir uno mejor. Hay un significado claro que puede dar a un número de versión, algo que es útil. Hay un problema que tenemos en el mundo de las personas que no actualizan sus módulos porque están usando la versión 1.03 y la última es 1.07 y mira, es solo una diferencia de 0.04. ¿Por qué molestarse en actualizar? Lo que no muestra es que hubo cuatro años entre 1.03 y 1.07. Microsoft lo descubrió, es por eso que compramos Office 2009 en lugar de Office 12 (también puede morderte si no lo lanzas a menudo, ¿quién querría Windows 98 en 2001?) Está justo allí en el número de versión. "Widgets 2007" te dice que tal vez deberías buscar una actualización.

Solía ​​usar fechas ISO como versiones. Si publicaste hoy sería la versión 20090309. Si tuviste que lanzar dos en un día, marca la hora y el minuto al final: 20090309.2051. Es fácil. Siempre sube. Transmite un significado inequívoco al usuario sobre el lanzamiento. Here's an example.

Ahora uso Semantic Versioning. Utiliza un triple punteado para transmitir tres datos importantes. ¿Se ha roto la API? ¿Se han agregado funciones? ¿Es solo una corrección de errores? El usuario debe saber que su proyecto está utilizando versiones semánticas, una desventaja sobre las versiones de fecha ISO. La ventaja es el tipo de información que transmite y que está bien definida.

Answer 11

Debería indicarles que marquen la versión del software de forma independiente del número de versión interno. Por ejemplo, iPhoto '09 es iPhoto versión 8.x. Microsoft hizo lo mismo.

Claramente, los principales proveedores se han movido hacia una versión de marca que tiene que ver con los lanzamientos de características al tiempo que permite a los desarrolladores ser más libres con sus números de versión. Esto satisface a todos y los chicos de marketing estarán especialmente contentos porque pueden idear una estrategia completamente nueva sobre cómo etiquetar las versiones de software.

Answer 12

No utilizaría números de versión mayor para representar reescrituras completas. Una nueva escritura es tan poco frecuente, que para muchos empleados solo tendrías que explicar que la versión 1 era "antes de trabajar aquí"."Si su producto se llamaba" Desbordamiento de pila ", simplemente llamaba a la reescritura" Desbordamiento de pila "y la anterior" Desbordamiento de pila vieja ". Esto sirve como un recordatorio constante para los usuarios del antiguo que necesitan migrar.