necesito una directriz o procedimiento que se describe la política de número de versión de código fuente como por cambios ocurrieron (mayor, menor, Micro), asignando particular versión de la liberación, etiquetado, etc.Fuente política de número de versión de código
Su guía en este respecto será muy apreciada ....
usted tiene algunas directrices públicas interesantes para empezar:
Es posible que desee ver el artículo de Wikipedia relacionando esto, aquí está: http://en.wikipedia.org/wiki/Version_number
seguir el formato a.b.c.d, a ser mayor, b Minor, c Build y d Revisión (aunque el intercambio de MS s esos dos últimos alrededor).
Mayor y Menor debe establecerlo usted mismo. Use Build and Revision o simplemente Revision para relacionar de nuevo al conjunto de cambios/revisión en su sistema de control de fuente.
Motivo para usar una combinación de compilación y revisión para esto es porque puede encontrarse con problemas donde la revisión es demasiado alta para ser utilizada en ciertas plataformas (pensando en AssemblyVersion en .NET aquí, 4 Int16 partes). De modo que podría usar la revisión div 1000 de SCS para c y la modificación 1000 para d.
De esta forma, desde cualquier número de versión (realmente solo desde partes de compilación y revisión), siempre podrá obtener un estado único de su código fuente.
Siempre he sido un fan de la forma en que la gente de Apache maneja versioning. La gente de Subversion también adoptó una variación (no puede encontrar el enlace desde que movieron los sitios web), lo que hace que la metodología sea consistente y fácil de entender.
Semantic Versioning es un método simple pero riguroso y completo para administrar números de versión. Se define un formato como
major.minor.patch
Por ejemplo, 1.0.0 o 2.1.2. Tenga en cuenta que los tres componentes principales siempre están presentes, y los componentes nunca se rellenan con ceros.
hay un componente pre-liberación opcional como
major.minor.patch-pre
que puede ser utilizado para todo tipo de versiones preliminares, como 1.0.0-alpha.1 o 1.0.0-rc.
Hay un componente opcional acumulación de metadatos como
major.minor.patch+build
que no se considera en relación con las versiones de pedidos.
La especificación de Versiones semánticas define claramente cómo se ordenan los números de versión en precedencia, de modo que todas las versiones preliminares preceden a la versión de lanzamiento correspondiente (sin el componente de prelanzamiento).
Tómese unos minutos para leer detenidamente las especificaciones. Parece simple al principio y es posible que tengas la tentación de echarle un vistazo sin leerlo, pero hay muchos aspectos importantes que están bien pensados.
El documento de control de versiones de Apache es bueno. Gracias por el puntero. Tiene una explicación detallada de algunas versiones sobre cómo manejar varios tipos de cambios. –