Olvídate de lo que dice Perl Best Practices. No es la Biblia, y simplemente sugiere usar palabras clave de RCS porque en el momento en que se escribió nadie estaba pensando en otros sistemas de control de origen. Su objetivo nunca debe ser el cumplimiento con la implementación particular de PBP, pero adaptando las ideas en PBP a su propia situación. Recuerde leer el primer capítulo de ese libro.
En primer lugar, vamos a arreglar sus supuestos:
usted 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 que sea diferente a la de las distribuciones anteriores. Todos los módulos en la distribución pueden tener la misma versión, y cuando lo hacen, todos pueden ser mayores que la versión de la última distribución.
¿Por qué no cambiar manualmente las versiones de un módulo que cambia rápidamente?Debes tener puntos definidos donde tu código se convierta en algo que las personas puedan usar. En esos puntos, hace algo para decir que ha tomado la decisión de distribuir el producto de su trabajo, ya sea como prueba o como versión estable. Cambia las versiones como una forma de decirle a las personas algo sobre su desarrollo. Cuando dejas que el sistema de control de origen lo haga simplemente porque te comprometes, estás perdiendo la oportunidad de denotar ciclos en tu desarrollo. Por ejemplo, normalmente utilizo dos publicaciones menores de lugar. Eso significa que recibo 100 lanzamientos antes de que el interrogatorio salga de wack y necesito encontrar la versión principal para restaurar un orden de clasificación adecuado. No es suficiente espacio de versión si dejo que el VCS maneje esto para mí.
Solía usar palabras clave RCS para enlazar las versiones de mis módulos para su registro o número de revisión, pero realmente no le gusta eso. Realizo muchas confirmaciones a un archivo antes de que esté listo para ser la próxima versión, y no necesito el cambio $VERSION simplemente porque solucioné un error tipográfico en la 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. Yo uso el ppi_version para cambiar todas las versiones a la vez:
ppi_version change 1.23 1.24
Todos mis archivos de módulo sale el mismo $VERSION. No necesito usar $VERSION para distinguirlos porque utilizo las funciones normales de control de fuente para hacer eso. No necesito $VERSION para vincularlo a una confirmación específica.
Si estoy trabajando para una nueva distribución desde la versión 1.23, empiezo a hacer las versiones de desarrollo 1.23_01, 1.23_02, y así sucesivamente, pero solo cuando estoy listo para 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 ese ciclo logre.
Cuando creo que es el comienzo de un nuevo ciclo, toco la versión de nuevo. 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 lanzo algo, también lo etiqueto en control de fuente. Puedo ver que mis principales puntos de desarrollo se alinean con el control de fuente con bastante facilidad.
Todo es mucho más fácil para mí. Nada está ligado al control de fuente que decido usar, así que no tengo que volver a hacer todo si cambio lo que uso.
Esta es una buena pregunta. Pero, ¿realmente recomiendan Perl :: Critic y/o PBP los números de versión respaldados por RCS? AFAI, realmente no les importa de dónde vienen esos números. – innaM
@Manni: sí, no les importa, pero aún recomiendan RCS como la "mejor práctica": "Una práctica común es usar la palabra clave $ Revision: 3629 $ para definir automáticamente la variable $ VERSION de esta manera: nuestra ($ VERSIÓN) = '$ Revisión: 3629 $' = ~ m {\ $ Revisión: \ s + (\ S +)} x; " –
Simpatizo porque actualmente estoy exactamente en la misma situación. Supongo que con cada vez más proyectos que usan git, la práctica será cada vez menos común. – innaM