Cambio de versión de código "reglas"

Sé que no hay reglas fijas sobre el control de la versión del software, pero tengo varias preguntas.

1) Cómo actualizar las versiones correctamente

Tengo un pequeño software que comencé hace un time y desde que empecé desde cero comencé con la versión 0.1.

A medida que agregué más funcionalidades, he estado actualizando el número menor. Ahora estoy en v0.5.7 (menor (.5) para nuevas funciones y revisión (.7) para correcciones de fallas y cambios menores), la cosa es que el progtwig está casi completo para su distribución, pero ahora me estoy perdiendo "Varias versiones menores, ¿cómo manejan ustedes esa situación? ¿Simplemente saltas los numbers?

Eso me lleva a la segunda pregunta.

2) Cuál es un buen número de versión inicial

Estoy a punto de comenzar un nuevo proyecto. Esta vez no es tan pequeño de un proyecto y será público y libre para modificarlo, no quiero tener los problemas mencionados anteriormente. Entonces, ¿cuál sería un buen punto de partida?

Pregunta extra:

3) ¿Está bien hacer numbers por encima de 10? como v1.25 o v2.2.30?

No he visto software con ese tipo de numeración (probablemente lo muestren solo en la sección de ayuda o en su página web), de nuevo soy consciente de que no hay reglas para eso, pero parece ser que hay un general consentimiento sobre cómo mantener los numbers de versión.

Las políticas de nubering de la versión pueden ser un poco locas a veces (vea Números de versión y JSR277 u Oracle , con su Oracle Database 11g Release 2: 11.2.0.1.0 .
Ver también Versiones de software es ridículo ).

Pero puede comenzar mirando la política de Eclipse Version Number como un buen comienzo.
Si realmente cree que necesita más de tres dígitos, esta explicación de la terminología VRMF Maintenance Stream Delivery Vehicle también es interesante, pero más aún para los softwares post 1.0, donde el fixpack y las soluciones provisionales están en order.


1 / "Enviarlo ya": 1.0.0

También conocida como la 1.oh-oh " 1.oh-oh ". Al less, está ahí y puedes comenzar a recibir comentarios e iterar rápidamente .

2 / 0.x si todavía faltan características principales ; 1.0.0 si las principales características están allí.

3 / Sí, pero solo diría para proyectos grandes con una vida útil de varios años (una década generalmente)


Tenga en count que "correctamente" (mientras se describe en longitud en Semantic Versioning 2.0.0 ) también puede guiarse por factores más pragmáticos:

Ver el anuncio de Git 1.9 (enero 2014) :

Un candidato de lanzamiento Git v1.9-rc2 ahora está disponible para probar en los lugares habituales.

He escuchado rumores de que a varias herramientas de terceros no les gustan los numbers de versión de dos dígitos (por ejemplo, "Git 2.0") y comenzaron a estallar a la izquierda y a la derecha cuando los usuarios instalan v1.9-rc1.
Si bien es tentador reírse de ellos por su suposition descuidada, también soy práctico y no me importa llamar al próximo lanzamiento v1.9.0 para ayudarlos.

Si tomamos esa ruta (y me inclino a seguir esa ruta en este momento), el esquema de control de versiones será:

  • La próxima versión candidata será v1.9.0-rc3 , no v1.9-rc3 ;
  • La primera versión de mantenimiento para la v1.9.1 será v1.9.1 (y la primera será v1.9.N ); y
  • La versión de la function después de v1.9.0 será v1.10.0 o v2.0.0, dependiendo de qué tan grande sea el salto de function que estamos viendo.

Incluso me enfrenté a este problema al definir el número de versión mientras desarrollaba con CRM, ya que quería implementar la misma construcción en todos los sistemas. Encontré una manera de resolverlo con Valor del sistema + Manual + randoms.

La información de versión para un ensamblaje consta de cuatro valores:

Versión principal . Versión menor . Número de compilation . Revisión

Lo que hace que la versión inicial 1.0.0.0 por defecto. Para que tenga más sentido, lo reemploop con

Lanzamiento de TFS . TFS Sprint . Cambiar número . Número de construcción incrementado

Supongamos que en su TFS una sola versión consta de 30 sprints y luego la versión se convierte en 2, por lo que los valores para la primera versión serán:

Lanzamiento de TFS : 1

Si el sprint actual es 4, el TFS Sprint tendrá

TFS Sprint : 4

Ahora la tercera parte es administrada por el desarrollador, para una versión inicial podemos tener 0 que puede incrementarse +1 para cada ChangeRequest o BugFix.

Cambiar número : 0 – representar la versión inicial Cambiar número : 1 – representar cambio Cambiar Numbe r: 2 – representar corrección de errores

Aunque para cada corrección de errores puede haber un cambio en el código, por lo que representa el cambio de código como pnetworkingeterminado. Pero para tener más sentido, puede tener el número impar para representar el cambio e incluso el número para representar la corrección de errores.

La última parte fue el número pnetworkingeterminado, afortunadamente .Net nos permite poner * para poner un número de compilation pnetworkingeterminado. Se mantiene en incremento con cada compilation / compilation que proporciona un sello de firma, si alguien más lo reconstruye.

Cómo implementar:

Abra AssemblyInfo.cs en la carpeta Propiedades y Comente el AssemblyFileVersion, esto hará que AssemblyFileVersion & AssemblyVersion sea igual.

 // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: [assembly: AssemblyVersion("1.4.2.*")] //[assembly: AssemblyFileVersion("1.0.0.0")] 

Entonces la versión final saldrá como: 1.4.2.4512 o algo

Los beneficios de este enfoque es que puede rastrear la tarea para la cual se genera el código. Solo mirando el número de versión puedo decir: "Hey, es el lanzamiento 1 para Sprint 4 y con algunos cambios de código.

En nuestra compañía, estamos utilizando el concepto de control de versiones de cuatro tokens. Es algo así como abcd kind:

 (major).(feature).(revision).(bug/refactoring) 

Está relacionado con los types de problemas que usamos en nuestro ciclo de vida de desarrollo. Podemos rastrear qué ha hecho o cambiado entre dos versiones siguientes de un vistazo. Al comparar dos numbers de versión siguientes, puede identificar el número y los types de problemas que se realizan. Para get más información, la documentation completa está aquí.