Buscando las mejores prácticas para la numeración de versiones de componentes de software dependientes

Estamos tratando de decidir una buena forma de numerar versiones para componentes de software, que dependen unos de otros.

Seamos más específicos:

El componente de software A es un firmware que se ejecuta en un dispositivo integrado y el componente B es su controlador respectivo para una PC normal (máquina Linux / Windows). Se comunican entre sí mediante un protocolo personalizado. Dado que nuestro producto también está dirigido a desarrolladores, ofreceremos versiones estables e inestables (experimentales) de ambos componentes (el firmware es de código cerrado, mientras que el controlador es de código abierto). Nuestra mayor dificultad es cómo manejar los cambios de API en el protocolo de comunicación.

Mientras estábamos implementando una verificación de compatibilidad en el controlador, que verifica si la versión del firmware es compatible con la versión del controlador, comenzamos a analizar varias formas de numeración de versiones.

Se nos ocurrió una solución, pero también tuvimos ganas de reinventar la rueda. Es por eso que me gustaría recibir algunos comentarios de la comunidad de programadores / desarrolladores de software, ya que creemos que este es un problema común.

Entonces aquí está nuestra solución:

Planeamos seguir la numeración de versiones major.minor.patch ampliamente utilizada y usar números menores pares / impares para las versiones estables / inestables. Si introducimos cambios en la API, aumentaremos el número menor.

Esta convención conducirá a la siguiente situación de ejemplo:

La rama estable actual es 1.2.1 y la inestable es 1.3.7. Ahora, un nuevo parche para inestable cambia la API, lo que hará que el nuevo número de versión inestable se convierta en 1.5.0. Una vez, la rama inestable se considera estable, digamos en 1.5.3, la lanzaremos como 1.4.0.

Estaría contento con una respuesta a cualquiera de las preguntas relacionadas a continuación:

• ¿Puede sugerir una mejor práctica para manejar los problemas descritos anteriormente?
• ¿Crees que nuestra convención "personalizada" es buena?
• ¿Qué cambios aplicarías a la convención descrita?

Los números de versión de IMHO son como nombres de productos; importante porque son visibles pero sin importancia porque son decoración en lugar de contenido.

Aún así, el número de versión, como el nombre de un producto, tiene significado. Y lo más importante que puede hacer es evitar la confusión. Aquí hay algunas expectativas comunes con respecto a los números de versión. En la medida en que no se cumplan estas excepciones, el usuario probablemente estará confundido:

Los números de versión están aumentando monotónicamente.
Esta es probablemente la expectativa más obvia y, al mismo tiempo, la menos probable que sea verdad. De un vistazo, el usuario espera que la versión 2.3.5 venga después de la versión 2.2.17 y tenga la misma o mejor tecnología. Pero, por supuesto, 2.3.x es una rama de desarrollo , y 2.2.x es estable , y 2.3.5 en realidad se lanzó en 2004 y la rama 2.2 todavía se está trabajando activamente y 2.2.17 se lanzó el pasado abril y contiene. .. Bueno, ya captas la idea. También podría llamar a la versión 2.2 "Papa" por todo el significado que lleva el número. ¡Bienvenido a la versión " Potato-17 "!

Versiones similares son actualizables / compatibles
Si tengo la versión 3.7 en mi computadora, y 3.8 sale con todos los nuevos frozbots brillantes, espero que con alguna actualización o parche o lo que sea, mi 3.7 pueda convertirse en 3.8 sin interrupción. Pero si estoy en 3.7 y lanzas 5.2, no soy tan optimista. Por supuesto, prefiero estar gratamente sorprendido en lugar de decepcionado.

El primer dígito es significativo
. Ni siquiera me molestaría en mencionar esto si Java no fuera tan prominentemente confuso al respecto. A menos que alguien te lo haya dicho, no esperarías que "Java 7" fuera en realidad la versión 1.7. Y la primera vez que escuchó esto, su respuesta fue casi segura: " ¿Qué? ... ¿Por qué? "

Claramente, el purista dirá que el número de versión principal solo cambiará si el cambio de plataforma no es compatible con versiones anteriores. Pero lo que realmente tiene la intención de dejar la compatibilidad hacia atrás cada vez ? A menudo, las revisiones de versiones principales son una decisión de marketing, no técnica; El absurdo de Java proviene de que ambos bandos se salen con la suya al mismo tiempo, con un efecto casi cómico.

Finalmente,
como acabo de mencionar, los números de versión a menudo tienen que ver tanto con el marketing como con la tecnología. Y eso está bien, ya que para eso son los números de versión: le informan de un vistazo sobre las novedades del software. Gran cambio de número significa un gran cambio de funcionalidad. Un pequeño cambio de número significa que casi no hay cambio de funcionalidad Eso es lo que la gente espera . Si es cierto o no, determina si sus números de versión tienen o no el mismo significado que sus usuarios piensan que tienen.

- EDITAR -
Olvidé mencionar esto, pero Caleb lo señaló muy bien: no use números de versión para indicar nada importante (por ejemplo, estable / inestable) sin hacerlo explícito en otro lugar. Sí, se sabe que el número de versión secundaria extraña indica el desarrollo, sino que lo hace uno de nosotros. El apodo de lanzamiento "inestable" de Debian es un buen ejemplo; o también podría usar un nombre de producto totalmente separado; "Frozbot 1.2" para el nombre de su producto y "Devbot 1.3" para su versión de desarrollo.

Una vez, la rama inestable se considera estable, digamos en 1.5.3, la lanzaremos como 1.4.0.

No no. Para inestable 1.5.3 estable debe comenzar desde 1.6.0 (y 1.4.x simplemente se perdió, si desea utilizar el control de versiones semántico)

Estás tratando de usar un valor para indicar dos cosas separadas.

Primero, tiene una "versión", que generalmente sirve para identificar las diferentes versiones e indicar el orden en que se realizaron. Como dijo tylerl, la versión siempre debería aumentar: no tendrá ningún sentido para los usuarios (y también podría causar mucha confusión interna) si cambia la versión de 1.5.3 a 1.4.0.

En segundo lugar, está tratando de indicar si una versión dada es estable o no.

Es posible indicar ambas cosas con un solo "número de versión", así como algunas tiendas usarán algún esquema de precios para indicar si un artículo está en oferta. Por ejemplo, los precios que terminan en '3' en una tienda cercana son precios de venta finales. Eso funciona bien para los empleados, que aprenden rápidamente cómo detectar un precio de venta, pero no es una excelente manera de informar a sus clientes sobre una venta. Por esa razón, también colocaron carteles cerca de los artículos en venta. Podrías hacer algo similar, como hacer el dígito menos significativo para las versiones estables incluso y hacerlo extraño para las versiones experimentales. Sin embargo, creo que si vas a lanzar algo que sea experimental, debes marcarlo claramente de esa manera. Puede agregar una 'X' al principio o al final de la cadena de versión, como:X.1.5.31.5.3.X. Usted podría incluso un número de versión experimental después de eso, por lo que podría liberar múltiples versiones experimentales todas basadas en la misma versión de la base: 1.5.3.X1, 1.5.3.X2.

También debe considerar que hay una larga tradición de usar "alfa" y los números de versión "beta" para indicar las versiones que pueden no ser estables o completa: 1.5.3a54. Asegúrese de tener una buena razón para apartarse de este esquema si decide hacer algo más, porque probablemente tendrá que explicar cualquier otra cosa a su comunidad de desarrolladores.

Sugeriría usar el formato major.minor.patch, usando una "etiqueta" de extensión para versiones estables / inestables, y un significado definido de los números mayor y menor:

major.minor.patch-stable|unstable

dónde

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

De esta forma, las dependencias se gestionan fácilmente y le indicarán a cada componente cliente / usuario cuándo deben prestar más atención a las nuevas versiones. Por ejemplo, si el componente A (1.1.0-estable) depende de B (5.4.534-estable) y se debe presentar una nueva versión de B (6.1.0-inestable), uno es inmediatamente consciente de que A tendrá que cambiarse, posiblemente sustancialmente .

Realmente me encanta la forma en que Hibernating Rhinos ha estado construyendo versiones RavenDb vis-a-vis: solo tienen un número de compilación cada vez mayor. Cuando obtienen uno estable, se marca estable. Pero todo es un candidato de liberación.