Bumping números de versión para nuevas versiones en archivos asociados (documentación)

Question

Me interesaría saber cómo usted maneja el que supera el número de versión para el nuevo número de versión.

¿Cómo se maneja el número de versión en los archivos asociados, como páginas de manual, etc.

El software es construir con la cadena de herramientas GNU autoconf modo, automake, etc están disponibles y se utilizan para el número de versión de la aplicación . Entonces esa información puede ser reutilizada.

git se utiliza como un vcs.

Una posibilidad sería introducir un objetivo adicional, nuevo en Makefile.am que hace un sed/awk para reemplazar el número de versión y las fechas en todos los archivos asociados. Ese objetivo podría llamarse una vez al comienzo (inmediatamente después de la bifurcación) del desarrollo de una nueva versión.

Luego, el proyecto podría compilarse con la información correcta cuando las personas hicieran un git clone del proyecto o cuando se realice un lanzamiento de tarball. Por supuesto, uno debe recordar ejecutar este objetivo cuando inicie el desarrollo de una nueva versión.

Otra opción sería hacer el reemplazo de sed/awk con un gancho para el destino dist. Pero esto pondría el repositorio de git del proyecto en un estado donde no hay un número de versión correcto asociado con los archivos asociados.

Prefiero hacer la primera solución, ya que también registra número correcto de la versión dentro del historial de git.

Cuando se realiza una sustitución sed/awk ¿Prefiere hacerlo "in-file" o con una plantilla de archivo liek la autoconf/automake herramientas hacen. Veo ventajas y desventajas en ambos métodos.

¿Cómo se maneja versionando de los archivos asociados. ¿Cambia ellos al comienzo de la fase de desarrollo, se cambia cuando justo antes de enviar , haces de reemplazo archivoentrada o prefiere el uso de una plantilla?

THX.

Answer 1

creo que la manera estándar de hacer esto es utilizar el sistema y el gancho de Git m4 o sed/awk para hacer la búsqueda/reemplazo como sugieres. Sólo se necesita una ficha especial en una observación en cada archivo (probablemente en la cabecera).

Aquí está la referencia sobre githooks y aquí hay un par de páginas escritas por gente que resuelve el mismo problema:

• http://groups.google.com/group/memcached/browse_thread/thread/b02e992ede0f0e89
• http://blog.rfwatson.net/2009/06/03/automatic-version-numbering-using-git/

Ambos se basan en almacenar el número de versión en una archivo en algún lugar de su árbol fuente.

también me encontré con un llamado tomó 0release que pretende automatizar la creación de liberación (y el establecimiento de números de versión).

Por último, en relación con los números de liberación, esto se trata en varias otras preguntas:

• What version numbering scheme do you recommend?
• How do you do version numbering in an agile project?
• What version number scheme for poorly planned, branched, and schizophrenic application
• Y más https://stackoverflow.com/search?q=release+numbering

Answer 2

utilizamos el clásico mayor .minor.patch system, que se aplica para lanzar candidatos como una 'etiqueta', tenemos una secuencia de comandos que etiqueta una confirmación como el número de versión, en lugar de usar un 'objeto de etiqueta'. Toda la numeración de la versión se hace 'a mano'. Funciona razonablemente bien, porque el número de versión se crea mediante las secuencias de comandos 'liberar en etapas', que es mucho más tarde en el proceso de desarrollo. No nos molestamos en usar ninguno de los ganchos de git, porque realmente no necesitamos hacerlo, si un compromiso no abandona el entorno de desarrollo, entonces no necesita un ID que no sea el código SHA interno.

Intentamos hacer cumplir que cada versión de 'parche' debe ser compatible con otras versiones con la misma etiqueta mayor y menor.

De esta forma, todo lo que tenga una etiqueta debería al menos compilarse, pero es posible o bastante probable que no funcione según las especificaciones.

Un refinamiento sería lograr que el departamento de control de calidad cree un objeto de etiqueta firmado en todo lo que sea 'QA aprobado', pero por ahora confiamos en otros documentos para eso.

Answer 3

Actualmente, una solución común es invocar AC_INIT con un argumento m4_esyscmd para generar la VERSIÓN desde git. Por ejemplo, configure.ac de autoconf contiene las líneas:

 
AC_INIT([GNU Autoconf], 
     m4_esyscmd([build-aux/git-version-gen .tarball-version]), 
     [bug-autoconf@gnu.org]) 

donde la acumulación de aux/git-versión-gen es un simple script que llama 'git describir' para generar el número de versión. (ver gnulib)

Existen inconvenientes en este enfoque, pero puede ser efectivo.