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

Toda la confusión proviene del semántica diferente que MS usa para «Número de compilación» y especialmente «Revisión». Los términos simplemente significan cosas diferentes.

La mayoría de las personas (incluido yo mismo) usan un esquema de numeración de versiones semánticas en el que simplemente obtienes un número BUILD más alto siempre que tenga que hacer una nueva construcción por cualquier motivo. Para nosotros, una revisión se considera simplemente 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 BUILD le dice cuál es el más reciente.

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

• número de confirmación 4711: Alice agregó la característica A
• CI produce la compilación 1.2.3.100
• número de confirmación 4712: Bob modificó la característica B
• número de confirmación 4713: Alice corrigió la característica 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 el siguiente build, también la modificación de Bob se convierte en parte de esa build. Si quieres estabilizar la rama actual, es posible que tengas problemas, ya que nunca puedes 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 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 «calientes» adicionales aplicados a esa rama de BUILD. Por lo tanto, la secuencia sería la siguiente:

• número de confirmación 4711: Alice agregó la característica A al tronco / maestro
• Carl crea la rama de compilación 1.2.100
• CI produce la compilación 1.2.100.0
• número de confirmación 4712: Bob modificó la característica B en el tronco / maestro
• número de confirmación 4713: Alice fija la característica A en la 1.2.100 rama
• CI produce la compilación 1.2.100.1

El término REVISIÓN puede referirse a

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

La diferencia clave entre los dos procesos es si desea o no la capacidad de aplicar revisiones a las compilaciones de CI y, por lo tanto, en qué punto del proceso se hace la rama. Este aspecto se vuelve importante cuando desea poder elegir una compilación en particular en cualquier momento después de que todas las pruebas hayan tenido éxito y promover 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 ramas se implementan exactamente de la misma manera: una etiqueta no es más que una rama ubicada debajo de /tags.

Ver también

De la sección de preguntas frecuentes en Estrategia de ramificación de TFS :

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

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

• Ahora puede discutir si es Es seguro trabajar directamente contra la rama Prod, piénselo 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 un análisis y una discusión más profundos con el cliente.

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

Comentarios

• ¡Esta es una gran respuesta! +1

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

major.minor [.build [.revision]]

Los componentes se utilizan por convención como sigue:

Mayor: Los ensamblados con el mismo nombre pero diferentes versiones principales no son intercambiables. Un número de versión más alto podría indicar una reescritura importante de un producto donde no se puede asumir la compatibilidad con versiones anteriores.

Menor: si el nombre y el número de versión principal en dos ensamblajes 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 más alto puede indicar un lanzamiento puntual de un producto o una nueva versión totalmente compatible con versiones anteriores de un producto.

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: Ensamblados con el mismo nombre, números de versión mayor y menor, pero las diferentes revisiones están destinadas a ser completamente 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

Comentarios

• Me desconcierta por qué nadie conoce este estándar, cada respuesta aquí afirma que la construcción va al final y no ‘ t entender que la revisión es muy simple; significa revisión. Lanzas una compilación y luego creas más compilaciones, pero cuando tienes que volver atrás y arreglar esa versión, actualizas la revisión para mostrar que la compilación particular que se publicó se modificó para una nueva versión
• +1 para una respuesta que tiene un número de compilación justificable. Simplemente incrementar el número es bastante inútil si la revisión permanece igual (a menos que tenga un sistema de compilación loco que depende del tiempo). Usar el número de compilación para indicar qué compilador, plataformas, etc. es útil.
• Build como recompilation of the same source parece ser un punto importante que se pasa por alto. Si ‘ es un cambio de código (que no ‘ t requiere un aumento mayor / menor completamente nuevo), entonces el Revision también debe cambiarse.
• @PeterX ¿Como en el caso de cambios específicos de la compilación cuando se vuelve a orientar?
• » Una diferencia en el número de compilación representa una recompilación de la misma fuente » parece contradecir la documentación. Una vez que realiza una revisión, ya no es la misma fuente. Tener BUILD antes de REVISION solo tiene sentido si una revisión es específica de una compilación que representa un » cambio de procesador, plataforma o compilador «. Así que supongo que lo que la mayoría ve como un aumento de REVISIÓN debería ser realmente un aumento MENOR cuando se usan estas descripciones. Aunque los documentos mencionan el uso de REVISION para las revisiones, supongo que las revisiones se aplicarían a todas las compilaciones y, por lo tanto, debería ser un aumento MENOR. ¡¡Solo quiero algo de coherencia lógica !!

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

1. Versión de control de código fuente que se publicó. Por ejemplo, si hubo un lanzamiento de la revisión # 12345, esto se puede rastrear haciendo que sea el número de compilación y si está parcheado, ahí es donde las revisiones pueden aumentar, ya que no es una nueva funcionalidad 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 del servidor de integración continua. En este caso, el servidor de 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 en bases de código.

Comentarios

• +1 para el n. ° 1. Me gusta usar el revisión de control de código fuente #, porque hace que sea mucho más fácil buscar errores reportados en esa versión en el control de código fuente.
• @MasonWheeler: funciona muy bien si estás en SVN. Pero cuando llegas a dcvs aterriza se pone ardilla y. Esta sería una de las cosas que más extraño de svn que ‘ agregaré.

La revisión se puede utilizar para parches de construye. Digamos que 2 equipos trabajan en un producto.

El equipo 1 es el equipo de desarrollo principal y produce compilaciones nocturnas 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. El equipo 2 está realizando una construcción de vez en cuando. Supongamos 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 lo hará tome esa compilación (43), solucione el problema y proporcione al equipo 2 la compilación 1.0.43.1. La solución también podría propagarse en la compilación principal, por lo que el cambio aparecerá en 1.0.52.0.

Hope esto es claro y útil.

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

Permítanme decir cómo lo veo y cómo lo uso ….

ProgramName versión major.minor.build.revision

mayor: 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 – access v-2 – accede a v-3 * todo el mismo programa pero completamente reescrito).

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

compilación: esta la utilizo para indicar cambios muy pequeños en la versión principal.minor publicada. Esto podría ser un cambio en el diseño, esquema de color, etc.

revisión: esto lo utilizo para indicar una corrección de error en el major.minor.build publicado actualmente – Hay ocasiones en las que no estoy progresando proyecto actual y surge un error. Este error debe corregirse y publicarse. Solo 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 la próxima versión mayor, menor o de compilación.

De esta manera, un proyecto terminado o estancado aún se puede arreglar y usar hasta que se publique la próxima versión. publicado.

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

Solo he visto un número de compilación como el último número en el ID de la versión. No estoy seguro de cómo se le ocurrió una revisión a un número de compilación. Supongo que si cambiara algunos de los recursos no compilados ( íconos, script de base de datos, etc.), tal vez, pero la mayoría de los proyectos en los que he trabajado recientemente también tienen todas esas cosas bajo control de versiones, por lo que el proceso de compilación las recoge al hacer el instalador / lanzamiento. Me gustan los números de compilación con sello 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.

Es lo que quieras que sea. Tiendo a usar year.month.day.hhmm para mi revisión principal.minor.build. Si produzco más de uno por minuto, algo anda mal. puede usar un simple incremento, o he visto algunos generadores elaborados para ellos. ¿Qué usted quiere que sea? Lo que necesitan hacer es lograr que llegue a la fuente utilizada para crear esa salida, así que cualquier cosa que le permita hacer eso.

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 de TeamCity que realmente crea la compilación. TeamCity crea un nuevo archivo AssemblyInfo con los números correctos durante el proceso de compilación.

Como jkohlhepp, usamos 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 de CI elimina un paso manual que de otro modo podría ser accidentalmente omitido; es fácil comprobar que un desarrollador no ha hecho un lanzamiento descarado de su PC de desarrollo (lo que daría como resultado que estos números fueran cero); y nos permite vincular cualquier pieza de software con el código que se generó a partir de y el trabajo de CI que lo creó, con solo mirar el número de versión, que ocasionalmente encontramos muy útil.

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 la gente solo usará 1234 ya que la parte 2 no cambia con frecuencia.

Comentarios

• El OP pregunta cuál es el número de compilación, no cuál es el número de compilación en el ID de revisión.