¿Cómo versionas tus proyectos?

Question

Entiendo que Microsoft usa esta plantilla al versionar sus productos: Major.Minor.Build.Revision.

Mayor cambia cuando los "desarrolladores" quieren mostrar que hay un gran cambio en el software y no se puede asumir la compatibilidad con versiones anteriores. Tal vez se haya realizado una reescritura importante del código.

El número menor representa una mejora significativa con la intención de compatibilidad con versiones anteriores.

Número de compilación es un pequeño cambio, por ejemplo, una recompilación de la misma fuente.

La revisión se utiliza para reparar un agujero de seguridad y debe ser completamente intercambiable. Tanto la compilación como la revisión son opcionales. Esta información se basa en MSDN Version Class.

¿Cómo versiona sus proyectos y por qué los versiona de esta manera?

Answer 1

Generalmente hacemos major.minor [.maintenance [.build]] donde trabajo, pero parece variar un poco por proyecto.

Mayor/menor de lo mismo que usted mencionó. el mantenimiento se incrementaría para correcciones pequeñas (errores) y compilación para cada vez que se ejecute el servidor de compilación.

Answer 2

Uso major.minor.point.revision, donde point es una versión de corrección de errores y la revisión es la revisión del repositorio. Es fácil y funciona bien.

Answer 3

ver esto: SO version number question

Answer 4

acabo de hacer MAJOR.MINOR. Como soy un desarrollador individual (con ayuda ocasional) trabajando en una aplicación web, la mayoría de las personas no se preocupan por las correcciones menores que yo hago. Así que solo repito las versiones menores a medida que introduzco las nuevas características y los números de versión principales cuando hago un poco de cambio/actualización. De lo contrario, simplemente ignoro las pequeñas correcciones en lo que respecta a los números de versión (aunque tengo números de revisión de Subversion si tengo que referirme por mi cuenta).

Answer 5

Trabajo en muchos proyectos pequeños y personalmente lo he encontrado útil.

PatchNumber.DateMonthYear

Esto es para pequeñas herramientas basadas en la web donde los usuarios pueden ver cuando la última actualización y la frecuencia con que se ha actualizado.

PatchNumber es el número de versiones que se han realizado y el resto se usa para mostrar a los usuarios cuando se publicó.

Answer 6

A menudo veo Xyz donde X es el año después del número de lanzamiento y yz es el mes del año. Es decir. 201 es enero, 2 años después del lanzamiento. Es decir. cuando el producto se lanza en mayo, su primer número de versión es 105. La versión en febrero del próximo año es 202.

Answer 7

Por lo general, la versión de nuestros proyectos se basa en la fecha de lanzamiento actual, YYYY.MM.DD. *, y dejamos que número generado automáticamente, por ejemplo, si tuviéramos un lanzamiento hoy sería 2008.9.26.BUILD.

Answer 8

Solo tengo un número. El primer lanzamiento es 001. La tercera versión beta de la segunda versión es 002b3, y así sucesivamente. Esto es solo para cosas personales mente, realmente no tengo nada 'liberado' en este momento, así que esto es toda teoría.

Answer 9

personalmente me gusta utilizar un esquema que se centra en el nivel de compatibilidad hacia atrás que los usuarios del proyecto/producto pueden esperar:

Antes de 1,0:

• 0.0.1 = Primera liberar
• 0 .-. X = actualización compatible actualización
• 0.X.0 = Hacia atrás incompatibles

Después de 1,0:.

• -.- X = Actualizar sin interfaz cambia
• -.X.0 = Actualizar con al revés adiciones interfaz compatible
• X.0.0 = actualización hacia atrás incompatible

El uso de la compatibilidad como punto central en el número de versión hace que sea más fácil para los usuarios, especialmente si el producto es una biblioteca, juzgar si pueden esperar o no una actualización segura o no.

Answer 10

Major.minor.patch.build con parche que es la revisión o versión de parche.

Si puede obtener control de calidad por y está en SVN, puede usar la revisión svn HEAD como el número de compilación. De esa forma, cada compilación describe de dónde viene en términos de control de fuente y qué hay en la compilación. Esto significa que usted tendrá generaciones que suben con huecos (1.0.0.1, 1.0.0.34 ....)

Answer 11

que empecé a usar un formato pseudo-similar a Ubuntu: Y.MMDD

Esto ayuda

por varias razones:

• que es más fácil para comprobar si hay requisitos de la versión: si (versión < 8,0901)die/salida/etc.;
• se puede genera automáticamente en su proceso de construcción

En ese segundo punto (rubí & rastrillo):

def serial(t) 
    t = Time.now.utc if not t.instance_of?(Time) 
    t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f 
end 

serial(Time.now)  #=> 8.0926 
serial(Time.now.utc) #=> 8.0927 

NOTA: t.strftime ("% m% Y. % d ") to_f - 2000 se encuentra con imprecisiones de punto flotante:. 8,09269999999992

Answer 12

Major.Minor.BugFix.SVNRevision

por ejemplo: 3.5.2.31578

• La revisión SVN le da la tranquilidad muy exacta del código enviado al cliente. Está absolutamente seguro de si esa corrección de errores estaba allí o no.
• También ayuda a encontrar el PDB adecuado en caso de que tenga un error de aplicación. Simplemente haga coincidir las Revisiones SVN en su servidor de compilación, copie el PDB a la ubicación EXE, abra el depurador y obtenga el rastreo de la pila de bloqueo.

Answer 13

tenía gusto de la manera Nantucket de versiones de su compilador Clipper en los años 80:

Clipper Winter 1984
Clipper Summer 1985
Clipper Winter 1985
Clipper Otoño 1986
Clipper Summer 1987

Oh y superposiciones ....

[obtiene lágrimas ]