¿De dónde viene el número de versión?

Question

Tengo un sistema de control de versiones (por ejemplo, Subversion) y ahora me gustaría configurar un proceso de compilación. Ahora tengo que crear un número de versión e insertarlo en el sistema. Pero, ¿de dónde viene el número de versión y entrar? Supongamos que quiero utilizar este común < major>. < menor>. < corrección de errores/revisión> esquema. ¿Debo pasar un número al script de compilación? ¿O debería pasar argumentos como increaseMajor, increaseMinor, increaseRevision? ¿O recomendaría crear una rama con el número que será detectado por el script de compilación?

Me imagino que el número de versión principal y secundaria debe colocarse manualmente en alguna parte. El número de revisión podría aumentarse de forma automática. Pero aún no sé dónde colocaría el número mayor y menor.

En mi caso, tengo algunos archivos php que me gustaría comprimir, pero antes tengo que insertar algunos números de versión en el archivo php.

---

He editado este post para tratar de hacer mi petición más clara:

no uso de Subversion, que era sólo un ejemplo. Y no quiero discutir el esquema del número de versión.

Imagine que quiero crear la versión 3.5.0 o 3.5.1. ¿Pasaría este número de versión a un script de compilación? ¿El script crearía la rama en el repositorio con este número o esperaría que alguien ya haya creado esta rama? ¿A mano? ¿O el script de construcción buscará el nombre de la rama (por ejemplo, '3.5.1) y lo usará para otras cosas? ¿Y el número de versión proviene de mi cerebro o se crea automáticamente (supongo que se crea el número mayor/menor que proviene de mi pequeño cerebro y número de revisión)? ¿O colocarías el número en un archivo que pueda insertarse en el repositorio?

Supongo que si utilizara una herramienta de gestión de versiones, insertaría allí el número de versión. Pero yo no uso uno todavía.

Answer 1

para la subversión, se puede tomar el número de revisión global y usar eso como número de "acumulación" o, mejor aún, no dependen de él en absoluto y gestionar versiones con etiquetas y/o ramas. El principal problema con la revisión global es exactamente eso, es global para el repositorio. Aumentará aunque algunas partes del repos no cambien.

Las versiones completamente disociadas de las revisiones del repositorio son en mi humilde opinión mejores. Usted tiene etiquetas, úselas.

Answer 2

La revisión de SVN o cualquier otro sistema de control de versiones no es lo mismo que su número de versión del producto (o incluso su número de compilación).

Existen varias formas de aplicar el número de versión. Comúnmente en la subversión puede crear una rama (o etiqueta, que es esencialmente la misma cosa) para una acumulación y si se trata de una versión de lanzamiento se crea una etiqueta para este ejemplo svn: //my-repo/releases/1.0.0

usted podría pasar un parámetro en su escritura de la estructura para obtener el código y usar eso como el número de compilación, o tener un directorio en el que el script de construcción utilizado, y svn switch esto a la rama que se quiere construir, la secuencia de comandos podría usar información svn para determinar qué versión estaba construyendo.

Answer 3

x.y.i.j 

Dónde x - Versión principal, y - Versión secundaria, i - Número de compilación, j - Número

Major version incrementos de revisión sobre los cambios importantes (nueva arquitectura, la nueva interfaz de usuario, etc.)

Minor version incrementos en cambios menores (mejora en el rendimiento, corrección de errores mayores, etc.),

Build number incrementos everyt Si haces un lanzamiento publico

Revision number se incrementa cada vez que se confirman cambios en el árbol de fuentes del proyecto.

prefiero señalar 0 como número de revisión en AssemblyInfo.cs y señalar el número real en el nombre del paquete de la versión (foo-1.1.7.110-source.zip)

Answer 4

estuvo de acuerdo con todo lo anterior sobre el uso de ramas y etiquetas. Además, los nombres de las ramas y los nombres de las etiquetas se pueden incorporar a un proceso de compilación con algunos scripts inteligentes.

El único tidbit que deseo agregar es que debes introducir tu revisión SVN en cada compilación. A veces es fácil volver a cierto punto con la revisión en lugar de conocer la etiqueta o la rama. 99% de la etiqueta/rama es lo suficientemente buena, pero la revisión es excelente para compilaciones incrementales/internas/continuas/de prueba.

Answer 5

Todas las ramas deben crearse manualmente. El script de compilación debería funcionar fuera de una etiqueta y/o bifurcación, comenzando con la comprobación (o puede estar actualizándola). Como parte del proceso de compilación, es una buena idea crear una etiqueta en la instantánea exacta que se genera.

Normalmente tendrías el número de compilación y una versión. El número de compilación puede incrementarse automáticamente y registrarse en el control de la versión como parte de la compilación (excepto para compilación basada en etiquetas, donde el número de compilación debe permanecer fuera del repositorio, otra razón para evitar compilaciones basadas en etiquetas).

La versión se almacena generalmente en un archivo que se actualiza manualmente una vez por ciclo de publicación. Se registra en la rama anterior y luego se deja solo. Por ejemplo, la línea principal tendría version = "3" en su archivo, la primera revisión en la rama de versión tendría la versión = "3.5", y si se necesita una versión de parche, la bifurque de la rama de publicación y verifique la versión = "3.5.1"