Una forma de definir el control de versiones es dar significado semántico a cada porción:

• Pase de N. x a N + 1.0 cuando la compatibilidad se rompa con la nueva relase
• Pase de N. M a N. M+1 cuando se agreguen nuevas características que no rompan la compatibilidad
• Vaya de N. M. X a N. M. X + 1 cuando se agreguen correcciones de errores

Lo anterior es solo un ejemplo you te gustaría definir las reglas que tengan sentido para ti. Pero es muy agradable para los usuarios saber rápidamente si se esperan incompatibilidades con solo mirar la versión.

Ah, y no olvides publicar las reglas que se te ocurran para que la gente sepa qué esperar.

El versionado semántico tiene un conjunto de directrices y reglas sobre cómo aplicar esto (y cuándo). Muy simple de seguir y simplemente funciona.

Http://semver.org/

Lo primero que recomendaría es familiarizarse con las diferencias entre la versión Ensamblada y la versión del archivo. Desafortunadamente,. NET tiende a tratarlos como lo mismo cuando se trata de los archivos AssemblyInfo, ya que generalmente solo pone AssemblyVersion y permite que el FileVersion tenga el mismo valor por defecto.

Ya que dijiste que este es un ensamblado compartido, asumo que quieres decir que se comparte a nivel binario (no incluyendo el proyecto en las diversas soluciones). Si ese es el caso que desea ser muy deliberado acerca de cambiar la versión del ensamblado, ya que es lo que.NET utiliza para nombrar el ensamblado (para permitirle ponerlo en el GAC) y también constituye el "nombre completo del ensamblado". Cuando la versión de ensamblado cambia, puede tener cambios de interrupción para las aplicaciones que la usan sin agregar entradas de redirección de ensamblado en la aplicación.archivo de configuración.

En cuanto a los nombres, creo que depende de cuáles son las reglas de nomenclatura de su empresa (si las hay) y el propósito de la biblioteca. Para exmaple, si esta biblioteca proporciona funcionalidad" core " (o nivel de sistema) que no es específica para ningún producto o línea de negocio en particular, podría nombrarla como:

CompanyName.Framework.Core 

Si es parte de una biblioteca más grande, o simplemente

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

En cuanto a cuándo incrementar los números de versión, sigue siendo bastante subjetivo y depende de lo que consideres que representa cada porción del número de compilación. El esquema predeterminado de Microsoft es Major.Menor.Construir.Revisión, pero eso no significa que no se te ocurren tus propias definiciones. Lo más importante es ser consistente en su estrategia y asegurarse de que las definiciones y reglas tengan sentido en todos sus productos.

En casi todos los esquemas de versiones que he visto las dos primeras porciones son Mayores.Menor. El número de versión mayor generalmente aumenta cuando hay cambios grandes y / o cambios de ruptura, mientras que el número de versión menor generalmente aumenta para indicar que algo cambió lo que hizo no fue una ruptura cambio. Los otros dos números son considerablemente más subjetivos y pueden ser el " build "(que a menudo es un valor de fecha serie o un número de actualización secuencial que cambia cada día) y el" revision " o número de parche. También los he visto invertidos (dando Mayor.Menor.Revision.Build) donde build es un número que aumenta secuencialmente desde un sistema de build automatizado.

Tenga en cuenta que las versiones mayor y menor del ensamblado se utilizan como el número de versión de la biblioteca de tipos cuando el ensamblado se exporta.

Finalmente, eche un vistazo a algunos de estos recursos para obtener más información:

Http://msdn.microsoft.com/en-us/library/51ket42z.aspx

Http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

Http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx