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

Nunca lo he visto escrito en esa forma. Donde trabajo, estamos usando 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 sistema operativo subyacente), MINOR es una versión menor (quizás algunas funciones nuevas) en una versión principal anterior, REVISION suele ser una solución para una versión secundaria anterior (sin funcionalidad nueva), y BUILDNUMBER se incrementa por cada última compilación de una revisión.

Por ejemplo, se puede lanzar una revisión a QA (control de calidad), y vuelven con un problema que requiere un cambio. El error se solucionaría y se liberaría de nuevo a QA con el mismo número de REVISIÓN, pero con un BUILDNUMBER incrementado.

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 de la siguiente manera:

     

Principal: los ensamblajes con el mismo nombre pero diferentes versiones principales son   No intercambiable. Un número de versión más alto podría indicar una mayor   reescritura de un producto donde no se pueda asumir la compatibilidad con versiones anteriores.

     

Menor: si el nombre y el número de versión principal en dos ensamblajes son los   Igual, pero el número de versión menor es diferente, esto indica   Mejora significativa con la intención de compatibilidad hacia atrás.   Este número de versión menor más alto podría 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 recompilación de   misma fuente Se pueden usar diferentes números de compilación cuando el procesador,   Cambios en la plataforma, o compilador.

     

Revisión: ensamblajes con el mismo nombre, mayor y menor versión   números pero diferentes revisiones están destinadas a ser totalmente   intercambiable. 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.

enlace

Toda la confusión proviene de la semántica diferente que MS utiliza 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) utilizan un esquema de numeración semántica donde solo obtiene un número de BUILD más alto cada vez que tiene que hacer una nueva compilación para cualquier razón. Para nosotros, una revisión se considera solo otro cambio de código, y la parte BUILD se incrementa automáticamente con cada ejecución de CI. Los módulos con el mismo MAJ.MIN.REV se consideran intercambiables, y BUILD le indica cuál es el más reciente.

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

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

Comopuedever,elhotfixnoeselúnicocambiocontenidoenlasiguientecompilación,tambiénlamodificacióndeBobseconvierteenpartedeesacompilación.Sideseaestabilizarlaramaactual,puedetenerproblemas,yaquenuncapuedeestarsegurodesiBobacabadeagregarunmontóndeerrores.

MSusaambostérminosdemaneradiferente.ElnúmerodeBUILDnoseincrementaautomáticamente,ensulugar,sepuedeconsiderarcomounaespeciederamadelanzamiento,paracongelarelcódigoutilizadoparaunaversiónparticulardelcódigo.LaREVISIÓNindicacambios"en caliente" adicionales aplicados a esa rama de CONSTRUCCIÓN. Por lo tanto, la secuencia sería la siguiente:

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

EltérminoREVISIÓNpuedereferirsea

• unarevisióndeproducto(asíescomolamayoríadelagentelousa)
• unarevisióndeunacompilacióndiariaenparticular(esoesloquehaceMS)

LadiferenciaclaveentrelosdosprocesosessideseaonotenerlacapacidaddeaplicarrevisionesalascompilacionesdeCIy,porlotanto,enquépuntodelprocesoserealizalasucursal.Esteaspectosevuelveimportantecuandodeseapoderelegirunaversiónenparticularencualquiermomentodespuésdequetodaslaspruebashayantenidoéxitoypromocionarexactamenteesaversiónalapróximaversiónoficialdesuproducto.

Ennuestrocaso,laherramientaCIcreaunaetiquetaderepositorio,porloquesiempretenemoslainformaciónnecesarialistaparausar,cuandoseanecesario.ConSVNsevuelveaúnmássimple,porquelasetiquetasylasramasseimplementanexactamentedelamismamanera:unaetiquetanoesmásqueunaramaubicadabajo/tags.

Vertambién

DelaseccióndePreguntasfrecuentesen Estrategia de bifurcación TFS :

  

¿En qué rama debería arreglar el ticket P1 (revisión)?

     

• El P1 se debe arreglar en la rama más cercana a la base de código 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 y al implementar los cambios en la producción, se arriesga a liberar código semiterminado o no probado de las iteraciones posteriores.

  

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

  

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

Hay al menos un par de cosas diferentes que puedo imaginar al hacer referencia al número de compilación:

1. Versión de control de fuente que fue lanzada. Por ejemplo, si hubo un lanzamiento de la revisión # 12345, esto se puede rastrear teniendo el número de compilación y si está parcheado es donde las revisiones pueden aumentar ya que no es una funcionalidad nueva que aumentaría las versiones principales o secundarias 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 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 grandes que conozco cuando se trata de números en bases de código.

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

Por motivos de simplicidad, algunos restablecen el número de compilación cada vez que se saltan los números MAYORES o MENORES.

La mayoría de los motores de integración continua permiten números de compilación únicos generados automáticamente.

La revisión se puede utilizar 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 El equipo 2 está construyendo de vez en cuando. Digamos que toman la versió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 todas las personas involucradas en el proyecto usan la misma compilación y usted necesita parchear compilaciones específicas.

Permítame decir cómo lo veo y lo uso ...

Versión de ProgramName major.minor.build.revision

major: Para mi 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 de edad: Esto significa que estoy agregando funcionalidad al proyecto publicado actual. Por ejemplo, tal vez agregué la capacidad de imprimir un recibo o la capacidad de importar imágenes. Básicamente, la funcionalidad adicional que quiero agregar ahora y no esperar la próxima versión importante para hacerlo.

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

revisión: Esto se usa para indicar una corrección de errores 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 necesita ser arreglado y publicado. 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 si inicié una nueva versión principal. Obviamente, la versión publicada debe parchearse mientras esperamos la próxima versión principal, secundaria o de compilación.

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

Espero que esto le brinde 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 hace que cualquier tipo de sentido real cuando se utiliza este tipo de control de versiones.

Solo he visto un número de compilación como el último número en la ID de la versión. No estoy seguro de cómo encontraría una revisión de un número de compilación. Supongo que si ha cambiado algunos de los recursos no creados (íconos, script DB, etc.), tal vez, pero la mayoría de los proyectos en los que he trabajado recientemente también tienen todo eso bajo el control de versiones, por lo que el proceso de compilación los recoge cuando Haciendo el instalador / release. Me gustan los números de compilación con marca de tiempo, aunque no del todo 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, 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 perderse accidentalmente; es fácil verificar que un desarrollador no haya hecho un lanzamiento descarado desde su PC de desarrollo (lo que daría como resultado que estos números fueran cero); y nos permite vincular cualquier pieza de software al código que se generó a partir de y el trabajo de CI que lo creó, solo con mirar el número de versión, que en ocasiones nos resulta 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 tú quieres que sea. Lo que deben hacer es hacerlo para que pueda acceder a la fuente utilizada para crear esa salida, así que lo que sea que le permita hacerlo.

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.

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