¿Qué “convención de nomenclatura de versión” utiliza? [cerrado]

Raramente estoy de acuerdo con Jeff Atwood, pero suelo seguir su opinión sobre la convención .NET de numeración de versiones .

  

(Versión principal). (Versión menor). (Número de revisión). (Número de compilación)

Más a menudo que no, para proyectos personales, encuentro que esto es una exageración. Las pocas veces en las que he trabajado en proyectos sustanciales como motores de búsqueda en C # me he adherido a esta convención y he podido utilizarla como un rastreador interno de manera efectiva.

Versiones semánticas ( enlace ) merece una mención aquí. Es una especificación pública para un esquema de control de versiones, en forma de [Major].[Minor].[Patch] . La motivación para este esquema es comunicar el significado con el número de versión.

No lo uso pero lo he visto y es una estructura interesante:

Year.Month.Day.Build

Se explica por sí mismo.

Intento usar la política de RubyGems Rational Versioning en la que:

• El número de versión principal se incrementa cuando se rompe la compatibilidad binaria
• El número de versión menor se incrementa cuando se agrega una nueva funcionalidad
• El número de compilación cambia para la corrección de errores.

Este es un enfoque muy detallado para la numeración de versiones:

• N.x.K , donde N y K son enteros. Ejemplos: 1.x.0 , 5.x.1 , 10.x.33 . Se utiliza para construcciones intermedias .
• N.M.K , donde N , M y K son enteros. Ejemplos: 1.0.0 , 5.3.1 , 10.22.33 . Se utiliza para lanzamientos .
• N.x.x , donde N es entero. Ejemplo: 1.x.x . Se utiliza para ramas de soporte .
• N.M.x , donde N y M son enteros. Ejemplo: 1.0.x . Se utiliza para lanzar sucursales .

Aquí está la imagen para una ilustración simple del enfoque de numeración de versiones:

PAsignificapre-alfaAsignificaalfaBsignificabetaARsignificaversiónalfaBRsignificaversiónbetaRCsignificacandidatoalanzamientoSTsignificaestablo

Lasventajasdeesteenfoquedenumeracióndeversiónsonlassiguientes:

• Representaaspectosespecíficosdelciclodevidadedesarrollodesoftwareágil.
• Tieneencuentalascaracterísticasespecíficasdeestructuradelrepositoriodecódigofuente.
• Esautoexplicativoparaaquellosqueseacostumbraronalospatrones.Cadapatrónrepresentaunartefactodiferente.Dichospatronessepuedenanalizaryutilizarfácilmenteparaotrosfines,comoelseguimientodeproblemas.
• Conjuntodepatronesdeversión,quebásicoparaelenfoquedecreacióndeversionesdescritosepuedeutilizarparareunirmétricasyplanificar.
• Secentraenlosconceptosdemadurezyniveldecalidad.Muyamenudo,losnúmerosdeversióncomo1.0.0seasignansinmuchanecesidad(cuandoelsoftwareestáenalfaprofunda).Elenfoquedenumeracióndeversionespresentadaspermiteestablecervariosnivelesdemadurez.Enelcasomássimple,tendrásolodosniveles:construcciónintermedia(N.x.K)yrelease(N.M.K).Ellanzamientosignificaquelapiezadesoftwareconelnúmerodeversióncompleto(N.M.K)hapasadoporalgúntipodeprocesodegestióndecalidaddentrodelaempresa/organización/equipoproveedor.
• Esunaevidenciadenaturalezaágiltantodeldesarrollocomodelaspruebas.
• Alientaelenfoquemodularalaestructurayarquitecturadelsoftware.

Tambiénhayun diagrama más complejo que representa el enfoque del control de versiones en detalle. También puede encontrar útiles diapositivas de presentación que describen la transición al enfoque de versiones y SCMFViz ilustra los principios básicos del enfoque de numeración de versiones. Las diapositivas de la presentación también explican por qué es importante mantener el mismo enfoque de versiones a lo largo de toda la vida del proyecto de software.

Personalmente, mi actitud hacia el uso de versión de fecha en lugar de números de versión reales supone que los desarrolladores del software con versiones de fecha:

• No sabe nada sobre el ciclo de vida del desarrollo de software . El desarrollo suele ser ágil e iterativo. El enfoque de numeración de versiones debe representar la naturaleza iterativa del proceso de desarrollo de software.
• No importa la calidad del software . El control de calidad y la garantía son ágiles e iterativos. Al igual que el desarrollo. Y el número de versión debe ser la evidencia de la naturaleza ágil e iterativa tanto del desarrollo como del control / garantía de calidad.
• No importa la arquitectura o idea de su aplicación. El número de versión principal ( N en N.M.K ) es responsable de la solución arquitectónica y del principio subyacente de la aplicación. El número de versión principal N debe cambiarse de acuerdo con los cambios en la arquitectura o los cambios en las ideas principales y los principios de su funcionamiento / funcionamiento.
• No tienen control sobre su código base . Probablemente hay una sola rama (troncal) y se usa para todo. Lo que personalmente no creo que sea correcto, ya que alienta a la base de código a convertirse en un gran basurero.

Este enfoque puede parecer un poco controvertido, pero creo que esta es la forma más sencilla de dar los números de versión apropiados para el software.

Para cada versión principal que lanzas, no es raro tener una versión funcional que llames internamente. Por ejemplo, en mi último trabajo, nos referimos a una versión principal con la siguiente convención de nombres inspirada en Ubuntu:

[condición enfermiza] [nombre de animal aliterado]

Que dio nombres como " Limp Lamprey ", " Wounded Wombat " y " Asteater Anteater ".

Asegúrese de que, a menos que sea un nombre realmente atractivo, no se filtre a sus clientes.

Generation.Version.Revision.Build (9.99.999.9999)

La generación rara vez cambia. Solo un gran giro en el producto: DOS - > Windows, reingeniería completa.

La versión es para grandes cambios incompatibles, nuevas funcionalidades, cambios en algunos paradigmas específicos del software, etc.

La revisión se realiza a menudo (características menores y corrección de errores).

La compilación es información interna.

git describe proporciona una buena extensión para cualquier convención de numeración que hayas elegido. Es bastante fácil integrar esto en su proceso de compilación / empaquetado / implementación.

Supongamos que nombra sus versiones de versión etiquetadas A.B.C (major.minor.maintenance). git describe en una confirmación dada encontrará el antecesor etiquetado más reciente de la confirmación, luego agregará la cantidad de confirmaciones desde entonces, y el SHA1 abreviado de la confirmación:

1.2.3-164-g6f10c

Si en realidad estás en una de las versiones, por supuesto, solo obtendrás la etiqueta (1.2.3).

Esto tiene la gran ventaja de que le permite saber exactamente de qué fuente compiló, sin tener que numerar cada compilación.

Major.Minor.Public (build) [alpha / beta / trial], como "4.08c (1290)"

• siendo Major el número de versión principal (1, 2, 3 ...)
• Menor es una versión menor de 2 dígitos (01, 02, 03 ...). Normalmente, el dígito de las decenas se incrementa cuando se agrega una nueva funcionalidad significativa, las que solo se aplican a las correcciones de errores.
• El público es la versión pública de la compilación (a, b, c, d, e), que a menudo es diferente de la versión secundaria si una versión secundaria nunca se publica como actualización pública
• compilación, siendo el número de compilación real que el compilador realiza un seguimiento de.
• con TRIAL, ALPHA, BETA X o RC X adjunto para esos casos especiales.

Prefiero los números de versión que asignan algún significado semántico. Siempre que pueda usar el número de versión para rastrear errores reportados con una versión en particular a los cambios que ocurrieron en el código fuente (y en su sistema de administración de actividades), probablemente esté usando el método correcto.

Uso .NET, así que estoy atascado con el sistema de numeración de versiones .NET, pero trato de dar un significado semántico a los números, por lo que con

major.minor.build.revision

• major = (hasta el proyecto)
• menor = (hasta el proyecto)
• build = build Número de Hudson (podría usar TeamCity o TeamBuild, etc. aquí)
• revision = subversion o bazar revisión (dependiendo del proyecto y para qué sirve)

Siempre nos aseguramos de que el número de versión sea visible de alguna manera (con nuestros programas por lotes basados en consola se imprime en la consola y un archivo de registro, con aplicaciones web en la barra de menú en la parte superior por lo general)

De esta manera, si los clientes reportan problemas, podemos usar el número de versión para rastrear si están usando la última versión y cuántos problemas hemos tenido con versiones particulares.

¡Se trata de la trazabilidad!

Utilizamos Major.Minor.Build # .YYMMDD [sufijo], ya que generalmente solo hacemos una compilación de producción en un día en particular (pero use el sufijo ab / c / d si hay más de uno ) y YYMMDD proporciona a los usuarios / clientes / administración una indicación de la antigüedad de la compilación, donde 6.3.1389 no.

Los números principales aumentan con las características significativas del producto (de pago).

Los números menores aumentan con las correcciones / mejoras (actualización gratuita).

La construcción siempre aumenta; No todas las compilaciones se envían, así que no es una progresión lineal.

Los números de versión deben tener suficiente información para evitar conflictos y corregir un error en los problemas de tipo de versión incorrecta, pero no deben transmitir información adicional que no sea relevante.

Por ejemplo, si usa la fecha en que los clientes pueden decir que tienen una versión anterior, y los parches contra versiones anteriores pueden tener versiones confusas.

Personalmente, me gusta versiones semánticas :

• Las liberaciones son Major . Minor . Patch
• Patch incrementa cada vez que lanzas una compilación.
• Minor incrementa cada vez que se agrega una funcionalidad compatible con versiones anteriores.
• Major se incrementa cuando la nueva funcionalidad no es compatible con versiones anteriores.
• Cuando Major == 0 estás en alpha / pre-release. Major > = 1 son tus lanzamientos públicos.
• Los números más bajos se restablecen a 0 cada vez que incrementas, por lo que

    

  1.5.3 - > 1.5.4 (corrección de errores) - > 1.6.0 (característica menor) - > 2.0.0 (cambio de ruptura)

  

              1.0.0
                |
              1.0.1
                |
(public 1.0)  1.0.2-----
                |       \
              2.0.0    1.1.0
                |        |
              2.0.1    1.1.1 (public 1.1)
                |
(public 2.0)  2.0.2-----
                |       \
              3.0.0    2.1.0
                         |
                       2.1.1 (public 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z es nuestro número de versión interna. X.Y es el número de versión pública, el que tiene un significado para nuestros clientes. Cuando una versión X.Y.Z se hace pública, nunca habrá una versión X.Y.(Z+1) : la versión pública siempre es la última de la serie.

X se incrementa cuando se lanza una versión principal.

Y se usa para las ramas de mantenimiento de esas versiones principales, solo para corregir errores.

Z se usa internamente y no tiene un significado fijo. Hasta ahora, creo una nueva versión Z cuando creo que la aplicación tiene un conjunto de características que son interesantes para mostrar a los desarrolladores y es relativamente estable. De esta manera, puedo mostrar una demostración de la "última buena versión conocida" de la aplicación cuando alguien la solicite. En un futuro próximo, planeo usar las versiones de número Z para nombrar un "objetivo" de funciones, en nuestro bugtracker.

Como nota al margen, usamos maven (con el comando release ) para incrementar el número de versión. Por lo tanto, también hay versiones de X.Y.Z-SNAPSHOT (lo que indica cualquier versión entre X.Y.(Z-1) y X.Y.Z ).