¿Cuándo cambia su número de versión mayor / menor / parche?

Posible duplicado:
¿Qué "convención de nomenclatura de versión" utiliza?

¿Cambia los números de versión mayor / menor / parche justo antes del lanzamiento o justo después?

Ejemplo: Acaba de lanzar 1.0.0 al mundo (¡huzzah!). Pero espera, no celebres demasiado. 1.1.0 saldrá en seis semanas! Entonces arreglas un error y haces una nueva construcción. ¿Cómo se llama esa construcción? 1.1.0.0 o 1.0.0.xxxy (donde xxxy es el número de compilación de 1.0.0 incrementado)?

Tenga en cuenta que puede tener 100 características y errores para entrar en 1.1.0. Por lo tanto, podría ser bueno llamarlo 1.0.0.xxxy, porque no estás cerca de 1.1.0. Pero, por otro lado, otro desarrollador puede estar trabajando en 2.0.0, en cuyo caso su compilación podría llamarse mejor 1.1.0.0 y su 2.0.0.0 en lugar de 1.0.0.xxxy y 1.0.0.xxxz, respectivamente.

Después de lanzar su software, el número de versión debe incrementarse inmediatamente.

¿Por qué?

Supongamos que sigue un esquema como el control de versiones semántico y que tiene un número de compilación en la versión. Entonces puede tener [Mayor]. [Menor]. [Parche]. [Construir]. Voy a llamar a la parte [Mayor]. [Menor]. [Parche] de la versión.

Creará varias compilaciones durante el desarrollo. Cada compilación es una instantánea de desarrollo de su próxima versión. Tiene sentido usar la misma versión para su desarrollo y versiones de lanzamiento. La versión indica lo suelte usted está trabajando hacia .

Si se está preparando para el lanzamiento y el software pasa todas sus pruebas, no querrá reconstruir y volver a probar el software solo porque tuvo que actualizar la versión. Cuando finalmente realice una versión, está indicando que "build 1.1.0.23" se denominará en adelante "versión 1.1.0".

El modelo de incremento después del lanzamiento también tiene sentido para la ramificación. Suponga que tiene una rama de desarrollo de línea principal y crea ramas de mantenimiento para versiones. En el momento en que crea su rama de lanzamiento, su rama de desarrollo ya no está vinculada al número de versión de ese lanzamiento. La rama de desarrollo contiene código que es parte de la próxima versión, por lo que la versión debería reflejar eso.

Generalmente trato de usar SemVer para números de versión internos. Es bueno poder saber algo sobre un lanzamiento basado en la semántica de su número de versión.

Durante el desarrollo, trato de cambiar los números de versión de inmediato (si es posible) . A veces es difícil saber si el cambio será un cambio importante o no (lo que influirá en mi número de versión), por lo que nada está "escrito en piedra".

Para abordar su ejemplo específico:

• Durante el desarrollo, las versiones preliminares serían 1.0.1-alpha.1, 1.0.1-alpha.2, etc.
• La versión final de la corrección de errores sería la versión 1.0.1.

Dicho esto, los números de versión del producto 'orientados al público' a menudo los establece el marketing y son completamente diferentes. Esto está fuera de mi control, así que no tiene sentido preocuparse por eso.

Asumamos ABCD en las respuestas. ¿Cuándo aumentas cada uno de los componentes?

Básicamente está determinado por la política de su empresa. Nuestra política de empresa es:

• A - Cambios o adiciones significativas (> 25%) en la funcionalidad o interfaz.
• B - pequeños cambios o adiciones en la funcionalidad o interfaz.
• C: cambios menores que rompen la interfaz.
• D: correcciones a una compilación que no cambia la interfaz.

En proyectos / organizaciones más grandes, los números de versión mayor y menor están controlados por los departamentos de marketing y generalmente se incrementan por razones de marketing. En mi organización, los grupos apuntan a lanzar un lanzamiento mayor y uno menor cada año. La expectativa es que las versiones principales contienen nuevas funcionalidades significativas y hay compatibilidad binaria entre las API para todas las versiones con el mismo número de versión principal. Sin embargo, el marketing puede optar por degradar un cambio de versión mayor a menor porque las características prometidas no se entregan o viceversa, por ejemplo, para saltar a la competencia de las ranas.

Los números de compilación mayor y menor (c y d en abcd) generalmente están controlados por el desarrollo. c es el número de compilación yd se usa para parches en una versión o versión particular de c.

En su caso, cuando cambia los números de versión mayor y menor es menos relevante que asegurarse de que los números de compilación mayor y menor sean precisos. En mi organización, cambiamos los números de compilación mayor y menor como parte del proceso de ramificación en el control de fuente. La rama principal generalmente contiene la última versión, pero es posible que el departamento de marketing aún no haya decidido qué número de versión tendrá el lanzamiento.

Intentamos y seguimos el ejemplo de Eclipse . Explica mejor de lo que puedo, pero efectivamente para nosotros funciona así:

Cuando publica 1.0.0.0, el número de versión al que cambia depende del tipo de cambio que esté realizando.

• Una versión que no afecta a la API, considere una corrección de errores detrás de escena que hace que la API actual funcione de la manera esperada, se publica en 1.0.1
• Una versión que se agrega a la API pero no cambia la API existente, es posible que haya agregado una nueva característica que no hace que los clientes actuales sean incomparables con la nueva versión. Esto también puede incluir cualquier número de soluciones anteriores.
• Un lanzamiento rompe la API actual, eliminando algo, cambiando algo de la manera que rompe la comparabilidad con los clientes actuales. Esto puede tener cualquier número de las correcciones anteriores también.

En cuanto a cómo usar la cuarta sección en el número de versión, usamos esto para diferenciar diferentes compilaciones en Nuget (la solución de administración de paquetes que usamos para .net). Esto nos permite evitar tener que borrar los cachés cada vez que necesitamos actualizar nuestro software inédito.

No hay próxima compilación. En esa rama

Versión idealizada de nuestro esquema.

La identificación de versión en cualquier rama es PRETTY_BRANCH_NAME-build y PRETTY_BRANCH_NAME se corrige en la creación de la rama.

Nuestro esquema de ramificación (*) es el siguiente:

En las ramas de nivel superior, el PRETTY_BRANCH_NAME de cada una es un nombre en clave, hablar del número de versión en ese nivel no tiene sentido, puede haber un esquema planificado pero cambiará antes del lanzamiento.

• una rama TNG ( la próxima generación ) donde se realiza el desarrollo a largo plazo. A menudo ni siquiera lo tenemos y nunca ha (liberado) subramas.

• una rama TCG ( la generación actual ) donde se realiza el desarrollo actual. PRETTY_BRANCH_NAME es un nombre en clave.

• una rama TPG ( la generación anterior ). A menudo no se realiza más desarrollo aquí, pero puede haber actividad en las subramificaciones.

Una subramificación está hecha de una rama de nivel superior (de TCG, en presencia de una migración lenta de TPG) cuando se inicia beta para un lanzamiento importante. PRETTY_BRANCH_NAME es algo así como "1.3.X" (X es la letra, no el dígito, significa que tenemos la intención de entregar 1.3 versiones desde aquí), la retroalimentación de la beta se tiene en cuenta aquí mientras se trabaja para la próxima versión principal la rama de TCG.

Idealmente, el lanzamiento debería ser una instantánea en esa rama, pero sabemos que no somos perfectos y, a menudo, necesitamos hacer cambios de último minuto mientras permitimos que otros continúen trabajando para el próximo lanzamiento menor. Por lo tanto, los subramas se realizan para la estabilización final con nombres bonitos como el número de versión oficial (en ese momento, incluso el marketing no querrá cambiarlo) como "1.3", "1.3.1" de la rama "1.3.X", La última versión de cada uno es el lanzamiento.

Si tuviéramos un cuarto nivel, los nombres de las subbandas habrían sido "1.3.0.X", de los cuales hubiéramos tenido sub ^ 3 ramas "1.3.0.0" "1.3.0.1".

(*) En el nivel de lanzamiento. Puede haber subramificaciones del proyecto en cada uno de estos.

Si está vendiendo software, tendrá una nueva versión importante cada vez que las ventas / marketing necesiten ganar una bonificación mayor :-).

Si tienes algo de control, entonces:

1. Lanzamientos importantes cuando:

   • Existe cierta incompatibilidad con la versión anterior que requiere conversión, etc., como Python 2 a Python 3.

   • Hay una gran cantidad de nuevas funcionalidades.

2. Versiones menores para cualquier pequeño cambio en la funcionalidad.

3. Lanzamiento de parche para corrección de errores.