¿Cuál es exactamente el número de compilación en MAJOR.MINOR.BUILDNUMBER.REVISION

Lo que pienso sobre los números de compilación es que cada vez que se crea una nueva compilación nocturna, se genera un nuevo BUILDNUMBER y se asigna a esa compilación. Entonces, para mi aplicación de la versión 7.0, las compilaciones nocturnas serán 7.0.1, 7.0.2, etc. ¿Es tan? Entonces, ¿de qué sirve una REVISIÓN después del número de compilación? ¿O se está incrementando la parte REVISIÓN después de cada compilación nocturna? Estoy un poco confundido aquí ... ¿nos referimos a cada construcción nocturna como un EDIFICIO ?

El formato se menciona aquí: AssemblyVersion - MSDN

Nunca lo he visto escrito de esa forma. Donde trabajo, utilizamos el formulario MAJOR.MINOR.REVISION.BUILDNUMBER, donde MAJOR es una versión principal (generalmente muchas características nuevas o cambios en la interfaz de usuario o el sistema operativo subyacente), MINOR es una versión menor (quizás algunas características nuevas) en una versión principal anterior, REVISION suele ser una solución para una versión menor anterior (sin nueva funcionalidad), y BUILDNUMBER se incrementa para cada última versión de una revisión.

Por ejemplo, una revisión puede ser lanzada a QA (control de calidad), y regresan con un problema que requiere un cambio. El error se corregirá y se devolverá al control de calidad con el mismo número de REVISIÓN, pero con un NÚMERO DE CONSTRUCCIÓN incrementado.

Toda la confusión proviene de las diferentes semánticas que MS usa para "Número de compilación" y especialmente "Revisión". Los términos solo significan cosas diferentes.

La mayoría de las personas (incluido yo mismo) usan un esquema de numeración de versión semántica en el que solo obtienes un número de CREACIÓN más alto cada vez que tienes que hacer una nueva compilación por cualquier razón. Para nosotros, un hotfix se considera solo otro cambio de código, y la parte BUILD aumenta automáticamente con cada ejecución de CI. Los módulos con el mismo MAJ.MIN.REV se consideran intercambiables, y el BUILD le dice cuál es el más reciente.

Sin embargo, el aumento de REVISION indica una nueva rama de lanzamiento permanente, por eso la colocamos antes de BUILD. La desventaja de ese enfoque es que podríamos obtener la siguiente secuencia de eventos:

• commit número 4711: Alice agregó la función A
• CI produce la compilación 1.2.3.100
• commit número 4712: Bob modificó la característica B
• commit número 4713: Alice arregló la función A (la "revisión")
• CI produce la compilación 1.2.3.101

Como puede ver, la revisión no es el único cambio contenido en la próxima compilación, sino que la modificación de Bob se convierte en parte de esa compilación. Si desea estabilizar la rama actual, puede tener problemas ya que nunca puede estar seguro de si Bob acaba de agregar un montón de errores.

MS usa ambos términos de manera diferente. El número BUILD no se incrementa automáticamente, sino que se puede considerar como una especie de rama de lanzamiento, para congelar el código utilizado para una versión particular del código. La REVISIÓN indica cambios "en caliente" adicionales aplicados a esa rama BUILD. Por lo tanto, la secuencia sería la siguiente:

• commit número 4711: Alice agregó la función A al tronco / maestro
• Carl crea una rama de construcción 1.2.100
• CI produce la compilación 1.2.100.0
• commit número 4712: Bob modificó la función B en troncal / maestro
• commit número 4713: Alice arregló la característica A en la 1.2.100rama
• CI produce la compilación 1.2.100.1

El término REVISIÓN puede referirse a

• una revisión del producto (así es como la mayoría de la gente lo usa)
• una revisión de una compilación diaria particular (eso es lo que hace MS)

La diferencia clave entre los dos procesos es si desea o no la posibilidad de aplicar revisiones a las compilaciones de CI y, por lo tanto, en qué punto del proceso se realiza la ramificación. Este aspecto se vuelve importante cuando desea poder elegir una compilación en particular en cualquier momento después de que todas las pruebas tuvieron éxito y promocionar exactamente esa versión para el próximo lanzamiento oficial de su producto.

En nuestro caso, la herramienta CI crea una etiqueta de repositorio, por lo que siempre tenemos la información necesaria lista para usar, cuando sea necesario. Con SVN se vuelve aún más simple, porque las etiquetas y las ramas se implementan exactamente de la misma manera: una etiqueta no es más que una rama ubicada debajo /tags.

Ver también

Desde la sección de preguntas frecuentes en la estrategia de ramificación de TFS :

¿En qué rama debo arreglar el ticket P1 (hotfix)?

• El P1 debe repararse en la rama más cercana a la base de código que se ejecuta en Producción. En este caso, el P1 debe repararse en la rama Prod. Al aplicar la corrección en cualquier otra rama y extender los cambios a la producción, corre el riesgo de liberar código semiacabado o no probado de las iteraciones posteriores.

• Ahora puede discutir si es seguro trabajar directamente contra la rama Prod, piense de nuevo, un P1 que requiere atención inmediata no debería ser un problema fundamental en el sistema. En caso de que sea un problema fundamental, debe agregarse a la cartera de pedidos del Producto, ya que puede requerir más análisis y discusión con el cliente.

Otra buena lectura es la guía de ramificación TFS

Microsoft describe el propósito de cada componente de un número de versión .NET en su documentación de MSDN para la Versionclase. Aquí está la porción relevante:

major.minor [.build [.revision]]

Los componentes se usan por convención de la siguiente manera:

Mayor: los ensamblados con el mismo nombre pero diferentes versiones principales no son intercambiables. Un número de versión superior podría indicar una reescritura importante de un producto donde no se puede suponer compatibilidad con versiones anteriores.

Menor: si el nombre y el número de versión principal en dos conjuntos son iguales, pero el número de versión menor es diferente, esto indica una mejora significativa con la intención de compatibilidad con versiones anteriores. Este número de versión menor mayor podría indicar un lanzamiento puntual de un producto o una nueva versión de un producto totalmente compatible con versiones anteriores.

Compilación: una diferencia en el número de compilación representa una recopilación de la misma fuente. Se pueden usar diferentes números de compilación cuando cambia el procesador, la plataforma o el compilador.

Revisión: los ensamblajes con el mismo nombre, números de versión principales y secundarios, pero se pretende que las diferentes revisiones sean totalmente intercambiables. Se puede usar un número de revisión más alto en una compilación que corrige un agujero de seguridad en un ensamblaje publicado anteriormente.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Hay al menos un par de cosas diferentes que podría imaginar la referencia del número de compilación:

1. Versión de control de origen que se lanzó. Por ejemplo, si hubo un lanzamiento de la revisión # 12345, esto puede rastrearse haciendo que sea el número de compilación y si está parcheado allí es donde pueden subir las revisiones, ya que no es una funcionalidad nueva que aumentaría las versiones mayores o menores y el número de compilación debe recordarse en caso de que alguien quiera ejecutar esa compilación nuevamente.

2. Identificador de servidor de integración continua. En este caso, el servidor CI puede numerar cada compilación que ejecuta y, por lo tanto, el número de compilación es lo que obtiene una compilación exitosa y la parte de revisión no es necesaria en este escenario.

Puede haber otros que no conozco, pero estos son los más importantes que conozco cuando se trata de números basados ​​en códigos.

Un número de compilación generalmente se incrementa en cada compilación, por lo que es único.

En aras de la simplicidad, algunos restablecen el número de compilación cada vez que se topan los números PRINCIPALES o MENORES.

La mayoría de los motores de integración continua permiten números de compilación únicos autogenerados.

La revisión se puede usar para parches de las compilaciones. Digamos que 2 equipos trabajan en un producto.

El equipo 1 es el principal equipo de desarrollo y produce una compilación nocturna con el siguiente esquema de versión 1.0.X.0, donde X se incrementa. Ahora están en la versión 1.0.50.0 Team 2 está tomando una versión de vez en cuando. Digamos que toman la compilación de la semana pasada que es 1.0.43.0 y comienzan a usarla. El equipo 1 avanza a 1.0.51.0 cuando el equipo 2 encuentra un problema en 1.0.43.0.

Ahora el equipo 1 tomará esa compilación (43), solucionará el problema y proporcionará al equipo 2 la compilación 1.0.43.1. La solución también se puede propagar en la compilación principal, por lo que el cambio aparecerá en 1.0.52.0.

Espero que esto sea claro y útil.

* La revisión es útil cuando no todos los involucrados en el proyecto usan la misma compilación y necesita parchear compilaciones específicas.

Déjame decirte cómo lo veo y lo uso ...

Nombre de programa versión major.minor.build.revision

importante: para mí es el proyecto actual en el que estoy trabajando. El número no cambiará hasta que comience un nuevo proyecto con el mismo nombre de programa. Esto significa que literalmente escribiré un nuevo programa del mismo género (ejemplo: acceso v1 - acceso v-2 - acceso v-3 * todo el mismo programa pero completamente reescrito).

menor: Esto significa que estoy agregando funcionalidad al proyecto publicado actual. Por ejemplo, quizás agregué la capacidad de imprimir un recibo o agregué la capacidad de importar imágenes. Básicamente, funcionalidad adicional que quiero agregar ahora y no esperar a la próxima versión principal para hacerlo.

compilación: Esto lo uso para indicar cambios muy pequeños en la versión principal publicada. Esto podría ser un cambio en el diseño, la combinación de colores, etc.

revisión: Esto lo uso para indicar una corrección de error en el major.minor.build publicado actualmente: hay ocasiones en las que no estoy progresando en el proyecto actual y surge un error. Este error debe ser corregido y publicado. Simplemente significa que estoy arreglando lo que ya publiqué para que funcione correctamente. También usaría esto si estoy trabajando en una nueva compilación, una nueva adición o comencé una nueva versión principal. La versión publicada obviamente necesita ser parcheada mientras esperamos el próximo lanzamiento mayor, menor o de compilación.

Por lo tanto, de esta manera, un proyecto terminado o estancado aún puede repararse y utilizarse hasta que se publique la próxima versión.

Espero que esto le dé a alguien una mejor comprensión de cómo funcionaría (o debería) este tipo de versiones. Para mí, es la única definición y práctica que tiene algún tipo de sentido real cuando se utiliza este tipo de versiones.

Solo he visto un número de compilación como el último número en la ID de lanzamiento. No estoy seguro de cómo llegaría a una revisión de un número de compilación. Supongo que si cambió algunos de los recursos no construidos (iconos, script DB, etc.), tal vez, pero la mayoría de los proyectos en los que he trabajado recientemente también tienen todo eso bajo control de versión, por lo que el proceso de compilación los recoge cuando haciendo el instalador / lanzamiento. Me gustan los números de compilación con marca de tiempo, aunque no exactamente como lo describe @David (me gusta major.minor.revision.HHMM). Sin embargo, donde trabajo, solo usamos un número secuencial que genera nuestro servidor de compilación.

Al igual que jkohlhepp, utilizamos la tercera parte de la versión para mostrar el número de revisión en SubVersion y la cuarta para mostrar el número de compilación de nuestro servidor de integración continua (Jenkins para nosotros). Esto nos brinda varios beneficios: tener el número de versión establecido por nuestro servidor CI elimina un paso manual que de otro modo podría perderse accidentalmente; es fácil verificar que un desarrollador no haya realizado una versión descarada de su PC de desarrollo (lo que resultaría en que estos números sean cero); y nos permite vincular cualquier pieza de software tanto al código del que se generó como al trabajo de CI que lo creó, simplemente mirando el número de versión, que ocasionalmente encontramos muy útil.

Es lo que quieras que sea. Tiendo a usar year.month.day.hhmm para mi major.minor.build.revision. Si estoy produciendo más de uno por minuto, algo está mal. simplemente puede usar un incremento simple, o he visto algunos generadores elaborados para ellos. ¿Qué es lo que quiere que sea. Lo que deben hacer es hacerlo para que llegue a la fuente utilizada para crear esa salida, por lo que lo que sea que le permita hacer eso.

Los dos últimos dígitos son el número total de compilación.

1.01.2.1234

el número de compilación es 2.1234, sin embargo, la mayoría de las personas solo usarán 1234 ya que la parte 2 no cambia con frecuencia.

Nuestro equipo usa el tercer número (revisión) como el número de revisión del repositorio de Subversion. Usamos el cuarto número (compilación) como el número de compilación de nuestro servidor de integración continua TeamCity que realmente crea la compilación. TeamCity crea un nuevo archivo AssemblyInfo con los números correctos durante el proceso de compilación.