perl - proyecto - git pull origin master

¿Cómo puedo actualizar automáticamente la versión $ VERSION de los módulos Perl con Git? (4)

Digamos, un equipo de programadores está haciendo una aplicación web en Perl y usa git para alojar su código. Ahora tienen un pequeño problema con la versión de sus módulos:

Perl::Critic y PBP recomiendan una variable $VERSION respaldada por RCS en el código
git recomienda explícitamente no utilizar números de revisión reemplazables en el código (con un buen razonamiento)

Entiendo por qué git no hace expansión de palabras clave. Sin embargo, puedo entender perfectamente la necesidad de números de revisión para un poco de código:

Necesita un control de versiones por separado para cada módulo, ya que es posible que desee utilizar el use versiones
Es probable que no desee cambiar los números de versión para cambiar rápidamente el módulo manualmente

Una versión global del producto para el empaquetado y la prueba se puede implementar fácilmente con las etiquetas y git describe , pero todavía no veo una manera de introducir la creación de versiones automática para módulos individuales.

¿Tienes alguna solución para mí?

¿Qué tal algo realmente perezoso que es solo un poco desordenado?

Puedes escribir un pequeño contenedor para git-add . Antes de llamar a git-add la envoltura empujaría un número de versión en algún lugar del módulo donde se pueda encontrar con una expresión regular.

Actualizar:

Actualmente no estoy usando algo así, pero estoy pensando seriamente en ello.

Mi razonamiento actual:

A diferencia de CVS o subversion, git no sabe nada acerca de los números de versión o revisión.
Los controladores de filtro necesitarían tener una fuente de información diferente para poder insertar un número de versión y esta fuente debería estar disponible en la máquina de cualquiera de los desarrolladores involucrados.
Por lo tanto, la mejor fuente para un número de versión es el propio archivo versionado.
Y para que el archivo sea utilizable como fuente para el siguiente número de versión, el número de versión debe ser parte de su correspondiente git blob.

Beneficios:

Esto es tan automático como es posible, no hay forma de olvidar actualizar su número de versión.
Transición suave de CVS / SVN a git. Cada compromiso introduce una nueva versión.

Inconvenientes:

El desarrollador perezoso que siempre hace git add . empujará los números de versión de los archivos que no tocó.
No parece haber una forma de imponer el uso del script de envoltura.

¿Qué usas para construir tu módulo Perl?

La solución utilizada por el kernel de Linux y por el propio proyecto Git es reemplazar los marcadores de posición "++ VERSION ++" (o "++ PROJECT_VERSION ++", o "@@ PROJECT_VERSION @@") por el sistema de compilación , en ese caso por Makefile. (En los archivos en C, esto se hace definiendo la constante del preprocesador "PROJECT_VERSION", mediante la -DPROJECT_VERSION=$(PROJECT_VERSION) '' -DPROJECT_VERSION=$(PROJECT_VERSION) '' que se pasa al compilador). En su caso, probablemente sería algo como Module::Install , Module::Build , o ExtUtils::MakeMaker .

El kernel de Git y Linux se usa para ese script GIT-VERSION-GEN que:

usa git describe si el proyecto se construye desde el repositorio de git,
GIT-VERSION-FILE archivo de version (o VERSION o GIT-VERSION-FILE ) si la compilación se realiza a partir de una instantánea (este archivo se crea al crear una instantánea / archivo),
y finalmente cb572206 número de versión predefinido, cuyo número se actualiza en commit, que marca la nueva versión lanzada (por ejemplo, cb572206 commit en el repositorio git, también conocido como commit v1.6.4.4 ).

Espero que eso te ayude.

Olvida lo que dice Perl Best Practices . No es la biblia, y simplemente sugiere el uso de palabras clave RCS porque en el momento en que se escribió, nadie estaba pensando en otros sistemas de control de fuente. Su objetivo nunca debe ser cumplir con la implementación particular de PBP, sino adaptar las ideas en PBP a su propia situación. Recuerda leer el primer capítulo de ese libro.

En primer lugar, vamos a arreglar sus suposiciones:

No necesita una versión separada para cada módulo en una distribución. Solo necesita dar a cada archivo de módulo una versión diferente a la de las distribuciones anteriores. Cada módulo en la distro puede tener la misma versión, y cuando lo hacen, todos pueden ser más grandes que la versión de la última distro.
¿Por qué no cambiar manualmente las versiones de un módulo que cambia rápidamente? Debes haber definido los puntos donde tu código se convierte en algo que las personas pueden usar. En esos puntos, hace algo para decir que ha tomado la decisión de que su producto de trabajo debe ser distribuido, ya sea como prueba o versión estable. Cambias las versiones como una forma de decirle a la gente algo sobre tu desarrollo. Cuando deja que el sistema de control de fuente haga eso simplemente porque está cometiendo, está perdiendo la oportunidad de indicar ciclos en su desarrollo. Por ejemplo, normalmente uso dos versiones menores de lugar. Eso significa que recibo 100 lanzamientos antes de que el cotejo desaparezca y tengo que cambiar la versión principal para restaurar un orden de clasificación adecuado. Eso no es suficiente espacio de versión si dejo que el VCS maneje esto por mí.

Solía usar palabras clave RCS para vincular las versiones de mis módulos a su registro o número de revisión, pero eso nunca me gustó. Me comprometo a un archivo antes de que esté listo para ser la próxima versión, y no necesito $VERSION cambio de $VERSION simplemente porque arreglé un error tipográfico de documentación. Habría grandes saltos en los números de versión porque había hecho muchos pequeños cambios.

Ahora solo cambio las versiones de todos mis archivos de módulo cuando estoy listo para lanzar una nueva distribución. Utilizo ppi_version para cambiar todas las versiones a la vez:

ppi_version change 1.23 1.24

Todos mis archivos de módulo obtienen la misma $VERSION . No necesito usar $VERSION para diferenciarlos porque uso las funciones normales de control de fuente para hacer eso. No necesito $VERSION para vincularlo a un compromiso específico.

Si estoy trabajando para obtener una nueva distribución desde la versión 1.23, comienzo a crear las versiones de desarrollo 1.23_01, 1.23_02, etc., pero solo cuando estoy listo para permitir que la gente pruebe esas versiones. Cambio la versión al comienzo del ciclo, no al final. Todos mis compromisos previos a la próxima versión ya tienen su próxima versión. También tomo notas sobre lo que quiero que logre ese ciclo.

Cuando creo que es el comienzo de un nuevo ciclo, vuelvo a golpear la versión. Cuando creo que tengo una versión estable, cambio el desarrollo $VERSION a uno estable, como 1.23_04 a 1.24. Cada vez que libero algo, también lo etiqueta en el control de código fuente. Puedo ver dónde mis principales puntos de desarrollo se alinean con el control de la fuente con bastante facilidad.

Todo es mucho más fácil de esta manera para mí. Nada está vinculado al control de código fuente que decido usar, por lo que no tengo que rehacer todo si cambio lo que uso.

Prefiero las versiones de tope manual al introducir cambios incompatibles, porque, ciertamente, no todos los cambios justifican el golpe.

También es posible que desee gitattributes la página de gitattributes '' gitattributes de gitattributes '' para el atributo de filter - quizás desee introducir su propio filtro para hacer las sustituciones basadas en la salida de '' git describe '' automáticamente.