.net versioning

.net - ¿Cómo versionas tus proyectos?



versioning (13)

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

Major 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 hacia atrás.

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

La revisión se usa para arreglar 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 la clase de versión de MSDN .

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

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. Ie 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. El lanzamiento en febrero del próximo año es 202.

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

Mayor / menor, el 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.

Major.minor.patch.build con parche que es la revisión o lanzamiento del parche.

Si puede obtener control de calidad por y estar en SVN, podría 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 tendrás compilaciones que van con brechas (1.0.0.1, 1.0.0.34 ...)

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

Antes de 1.0:

  • 0.0.1 = Primer lanzamiento
  • 0 .-. X = actualización compatible hacia atrás
  • 0.X.0 = actualización incompatible hacia atrás

Después de 1.0:

  • -.-. X = Actualización sin cambios de interfaz
  • -.X.0 = Actualización con adiciones de interfaz compatibles hacia atrás
  • X.0.0 = actualización incompatible hacia atrás

El uso de la compatibilidad como el 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 y segura .

Trabajo en muchos proyectos más pequeños y personalmente he encontrado que esto es útil.

PatchNumber.DateMonthYear

Esto es para pequeñas herramientas basadas en web donde los usuarios pueden ver cuándo fue la última actualización y con qué frecuencia se ha actualizado.

PatchNumber es la cantidad de lanzamientos que se han realizado y el resto se usa para mostrar a los usuarios cuando se publicó.

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.

Usualmente versionamos nuestros proyectos basados ​​en la fecha de lanzamiento actual, YYYY.MM.DD. *, y dejamos que el número de compilación se genere automáticamente, por lo que, por ejemplo, si tuviéramos un lanzamiento hoy, sería 2008.9.26.BUILD.

Solo tengo un número. El primer lanzamiento es 001 . La tercera 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.

Empecé a usar un formato pseudo-similar como Ubuntu: Y.MMDD

Esto ayuda por algunas razones:

  • es más fácil verificar los requisitos de la versión: if (versión <8.0901) die / exit / etc. ;
  • puede ser generado automáticamente en tu proceso de construcción

En ese 2º punto (ruby & rake):

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 ("% Y.% m% d"). To_f - 2000 se ejecuta en imprecisiones de coma flotante: 8.09269999999992

Major.Minor.BugFix.SVNRevision

Ej .: 3.5.2.31578

  • La Revisión de SVN le proporciona la paz 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 en la ubicación EXE, abra el depurador y obtenga el rastreo de la pila de fallos.

Me gustaba la forma Nantucket de versionar su compilador Clipper en los años 80:

Clipper Winter 1984
Clipper Summer 1985
Clipper Invierno 1985
Clipper otoño 1986
Clipper Summer 1987

Oh y superposiciones ....

[se pone lloroso]

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).