2009-02-22 21 views

Respuesta

7

La ventaja del tiempo es que obtiene un número de versión creciente y que codifican la marca de tiempo.

La ventaja de utilizar números más tradicionales es que es más fácil de entender para las personas. Todos sabemos más o menos lo que significa "v2.1", por ejemplo.

En general, sugiero usar el tiempo porque la información agregada es útil. La ventaja de los otros números es solo para marketing, y para eso puedes hacerlo de todos modos.

Por ejemplo, ¿por qué no tener ambos, a la "v2.1.20090214." Ahora tiene marketing en la sección major.minor y utilidad en la sección "build".

+6

Si usa una fecha como número de versión, use el formato AAAAMMDD. Es el único que casi nadie puede leer sin ambigüedades, y tiene la ventaja de ordenar léxicamente en el orden correcto. – Evan

+1

(Para los parroquiales entre nosotros, algunos países escriben sus fechas en formato MM-DD-YYYY, y la mayor parte del resto de la palabra sana los escribe en formato DD-MM-AAAA o AAAA-MM-DD). – Evan

+9

Tenga en cuenta que en Win32 (y por lo tanto, .NET), los números de versión tienen un límite de 16 bits por componente, por lo que 20090214 como un componente no es posible. –

3

Acabo de dejar AssemblyVersion en "1.0. *" Y elimino cualquier AssemblyFileVersion.

Luego puedo incrementar los números de las versiones mayor y menor según me parezca apropiado y dejar que la compilación y la revisión base de DateTime se establezcan automáticamente.

A menos que tenga herramientas de compilación alternativas que controlen el número de compilación y revisión de acuerdo con algún otro esquema, no veo ninguna ventaja real al configurarlas manualmente.

+0

Estoy haciendo exactamente lo mismo. –

1

Uso algunos scripts de compilación que actualizan mi revisión en base a la revisión de SVN. Eso hace que sea trivial rastrear un dll de vuelta al código fuente que lo creó.

El tiempo es más complicado; debe comenzar a buscar en el panel de historial, dónde, ya que la mayoría de las herramientas de control de origen tienen una función de "obtener revisión".

0

¿Por qué elegir? Puede usar un formato como Major.Minor.YYMMDD.Revision y obtener lo mejor de ambos mundos.

Editar Como se señaló en los comentarios a veces el rango de cada campo está restringido. En ese caso, puede usar Major.Minor.YMMDD.Revision.

¡Con suerte cambiaría la versión menor al menos cada 10 años!

+2

corrígeme si me equivoco, pero según MSDN en "http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx" cada componente debe ser un número entre 0 y 65535. YYMMDD sería demasiado grande. "Major.Minor.YYYY.MMDD" cabría pero es incómodo :-( – angrifel

0

Una desventaja de la numeración de versiones basada en fechas es la percepción negativa del software anterior.

Aunque, lo uso de todos modos porque encaja muy bien en mis proyectos.

+1

No siempre es una desventaja. Esa percepción negativa se puede utilizar para vender su nueva versión. –

2

El uso de hora/fecha tiene uno más (aparte de los ya mencionados en otras respuestas aquí) Desventaja:

si estás equipo de desarrollo se distribuyen en diferentes zonas horarias, nunca estará seguro de cuál dos versiones construidas con una hora de diferencia son las más nuevas. A menos que también la versión de la zona horaria o forzar la fecha/hora para estar en, por ejemplo, GMT.

4

La ventaja de utilizar el esquema major.minor.revision es la semántica.Hay un método para actualizar cada uno de estos números:

El cambio de número importante significa que la nueva versión es incompatible con la anterior y cualquier dependiente de la versión anterior requerirá cambios de código para actualizar al nuevo paquete.

El cambio de número menor significa que la nueva versión es retrocompatible con la versión anterior pero tiene mejoras significativas con respecto a la versión anterior.

El número de revisión se actualiza cada vez que se aplica una corrección de errores a la compilación, de modo que no se produce un cambio de compatibilidad ni se introducen características más nuevas.

Al especificar las dependencias, puede decir que depende de foo-1.0.0 - foo-1.99.999, y puede estar seguro de que no terminará con una actualización del paquete que rompe su aplicación.

Si comenzó con una versión secundaria más alta de una dependencia, por ejemplo, foo-1.4.22, debe especificar la dependencia como foo-1.4.22 - foo-1.99.999, para que no termine instalar una versión anterior a la 1.4.x, que podría tener alguna funcionalidad/mejora faltante de ella.