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

Question

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

1) Cómo actualizar versiones correctamente

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

Cuando agregué más funcionalidad, 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 programa 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 números?

Eso me lleva a la segunda pregunta.

2) ¿Qué es una buena versión de partida número

estoy a punto de iniciar 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?

Bono pregunta:

3) ¿Está bien para hacer los números 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 consentimiento general sobre cómo mantener los números de versión.

Answer 1

políticas Versión nubering puede ser un poco loco a veces (ver Version numbers and JSR277, o Oracle, con su base de datos Oracle 11g Release 2:. 11.2.0.1.0
Véase también Software Versioning is Ridiculous).

Pero puede comenzar por buscar et Eclipse Version Number policy como un buen comienzo.
Si realmente cree que necesita más de tres dígitos, este V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation también es interesante, pero más para los softwares posteriores a 1.0, donde el fixpack y las soluciones provisionales están en orden.

---

1/"enviar ya": 1.0.0

También conocida como la versión "1.oh-oh". Al menos, está por ahí y puede comenzar a recibir comentarios e iterar rápido.

2/0.x if características principales siguen desaparecidas; 1.0.0 si las principales características están allí.

3/Sí, pero yo diría que sólo para grandes proyectos con una vida útil de varios años (una década por lo general)

---

Tenga en cuenta que "correctamente" (mientras se está describiendo en longitud en Semantic Versioning 2.0.0) también Déjese guiar por factores más pragmáticos:

Véase el announcement for Git 1.9 (Januaury 2014):

Una versión candidata Git v1.9-RC2 ya está disponible para las pruebas en los lugares habituales.

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

Si vamos por ese camino (y me inclino a ir por ese camino en este momento), el esquema de versiones será:

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

Answer 2

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

La información de versión de un ensamblado consta de cuatro valores:

Major Version. Versión secundaria. Número de compilación. Revisión

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

TFS Release. TFS Sprint. Número de cambio.incrementa número de compilación

Supongamos que en su TFS un solo lanzamiento consta de 30 carreras y después de que la liberación se convierte en 2, por lo que los valores de la primera versión será:

TFS lanzamiento: 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 de: 0 - representar versión inicial número de cambio de: 1 - representar el cambio Cambio Numbe r: 2 - Solución de error representan

Aunque para cada corrección de errores que podría haber una cambio en el código, por lo que representa el cambio de código por defecto. 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 predeterminado, afortunadamente .Net nos permite poner * para poner un número de compilación predeterminado. Se mantiene en incremento con cada compilación/compilación que proporciona un sello de firma, si alguien más lo reconstruye.

Cómo implementar:

Abiertas las AssemblyInfo.cs en la carpeta Propiedades y Comentario del AssemblyFileVersion, esto hará que el AssemblyVersion AssemblyFileVersion & misma.

// 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")] 

Así que la versión final saldrá como: 1.4.2.4512 o algo

Los beneficios de este enfoque es que se puede realizar un seguimiento de la tarea para la cual se genera el código. Con sólo mirar el número de versión que puedo decir, "bueno, ¡es la liberación 1 para Sprint 4 y con un poco de cambio de código

Answer 3

En nuestra empresa, estamos utilizando cuatro concepto de versiones símbolo Es algo así como ABCD tipo..:

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

está relacionado con los tipos de emisión que utilizamos en nuestro ciclo de vida de desarrollo. podemos realizar un seguimiento de lo que ha hecho o ha cambiado entre dos versiones siguientes de un vistazo. al comparar dos siguientes números de versión se puede identificar el número y los tipos de problemas realizados. Para obtener más información, full documentation is here.