Cómo hacer números de versión?

X. y. z. g

Los incrementos en g son inestables. (o RCs) los incrementos en z son estables y significan correcciones de errores.
los incrementos en y son estables y significan nuevas características.
los incrementos en x son estables, versión principal sin 100% de compatibilidad con versiones anteriores.

Una vez escribí una elaborada "guía de estilo de versiones" para un gran proyecto mío. El proyecto no se materializó, pero la guía de estilo está todavía disponible en línea. Es mi opinión personal, tal vez sea útil (o inspiradora) para usted.

Cuidado, es un texto largo, y entra en el control de versiones de componentes vs.el control de versiones de productos y cosas por el estilo. También expresa fuertes opiniones sobre algunos esquemas de versiones populares en la comunidad OSS, pero los tengo, así que los expreso. ;-)

No estoy de acuerdo con usar el número de revisión de Subversion, por ejemplo. Es posible que desee mantener una versión publicada mientras continúa el desarrollo en TRUNK, por lo que configurará una rama de mantenimiento, y el control de versiones de su número de revisión se irá por el desagüe.

Edit: Como resumen, distingue entre el control de versiones de los archivos de origen, los componentes y el producto en general. Utiliza un sistema de versoning x.y separado para los componentes y el producto, con una agradable interdependencia entre los dos que hace que el seguimiento de qué versión de componente pertenece a qué versión del producto trivial. También habla de cómo manejar los ciclos alfa / beta / release / patch sin romper el sistema. En realidad, es un modus operandi para todo el ciclo de desarrollo, por lo que es posible que desee elegir. ;-)

Edit 2: Como muchas personas encontraron mi artículo útil para hacer de esto una "Buena Respuesta", empecé a trabajar en el artículo de nuevo. Versiones PDF y LaTeX ya están disponibles, un completo reescribir incluyendo un mejor lenguaje y gráficos explicativos seguirá tan pronto como pueda encontrar el tiempo. Gracias por sus votos!

Obtener un poco de inspiración de Wikipedia: "Software versioning"

Otra opción" nueva "y" relativamente popular " es Versionado semántico

Resumen:

Dado un número de versión MAYOR.MENOR.PATCH, incrementa el:

1. Versión PRINCIPAL cuando realiza cambios incompatibles en la API,
2. Versión MENOR cuando se agrega funcionalidad de una manera compatible con versiones anteriores, y
3. Versión de parche cuando se hace correcciones de errores compatibles con versiones anteriores.

Las etiquetas adicionales para los metadatos de pre-lanzamiento y compilación están disponibles como extensiones al MAYOR.MENOR.Formato de PARCHE.

Basado en mi experiencia con la gestión de dependencias a nivel de plataforma empresarial compleja y el control de versiones de versiones, he venido a recomendar un enfoque que me gusta llamar Control de versiones semisemántico.

Básicamente se basa en El Versionado semántico 2.0 pero no es tan estricto.

Semi-Semántica Versión Segmentos:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Formato del Segmento de la Versión Principal:

COMERCIALIZACIÓN.PRINCIPAL.MENOR.PARCHE

Cada segmento debe permitir se recomiendan los alfanuméricos, pero los numéricos puros para los cambios incrementales lógicos.

Al igual que SemVer, recomiendo Los componentes Mayor, Menor y Patch para representar niveles de compatibilidad inversa, pero también recomiendo anteponer un componente de Marketing . Esto permite a los propietarios de productos, epopeyas/grupos de características y preocupaciones comerciales eliminar el componente principal independientemente de las preocupaciones de compatibilidad técnica.

A diferencia de otras respuestas, no recomiendo agregar una compilación número al segmento primario. En su lugar, agregue un Segmento posterior al lanzamiento después de un '+' (por ejemplo: 1.1.0.0+build.42). SemVer llama a estos metadatos de compilación, pero creo que el Segmento Posterior al Lanzamiento es más claro. Este segmento es ideal para declarar los datos del sufijo como no relacionados con la información de compatibilidad en el Segmento de publicación principal . Sus compilaciones de integración continua pueden recibir el número de versión anterior adjunto con un número de compilación incremental que se restablece después de cada versión principal (por ejemplo: 1.1.0.0 - > 1.1.0.0+build.1 - > 1.1.0.0+build.2 -> 1.1.0.1 ). A algunas personas alternativamente les gusta poner el número de revisión svn aquí o el sha de confirmación de git para que sea fácil vincularlo al repositorio de código. Otra opción es usar el segmento post-release para revisiones y parches, aunque podría valer la pena considerar agregar un nuevo componente de versión principal para eso. Siempre se puede dejar caer cuando el componente de parche se incrementa, ya que las versiones están efectivamente alineadas a la izquierda y ordenadas.

En además de los segmentos release y post-release, la gente a menudo quiere usar un Segmento Pre-Release para indicar pre-releases casi estables como alphas, betas y release candidates. El enfoque SemVer para esto funciona bien, pero recomiendo separar los componentes numéricos de los clasificadores alfanuméricos(por ejemplo: 1.2.0.0 + alfa.2 o 1.2.0.0 + RC.2). Normalmente, se activaría el segmento de lanzamiento al mismo tiempo que se agregaba el segmento posterior al lanzamiento y, a continuación, se eliminaría el segmento previo al lanzamiento la próxima vez bump ellos segmento de la versión principal (por ejemplo: 1.0.1.2 -> 1.2.0.0-RC.1 -> 1.2.0.0). Los segmentos de pre-lanzamiento se agregan para indicar que la versión de lanzamiento está llegando, generalmente solo un conjunto fijo de características para pruebas y compartir más en profundidad que no cambia minuto a minuto en función de más confirmaciones.

La belleza de tener todo esto semánticamente definido de una manera que cubre casi todos los casos de uso es que puedes analizar, clasificar, comparar y de incremento en una forma estándar. Esto es especialmente importante cuando se utilizan sistemas de CI para aplicaciones complejas con una gran cantidad de pequeños componentes versionados de forma independiente (como microservicios), cada uno con sus propias dependencias administradas.

Si estás interesado, escribí un analizador semisemántico en ruby. Necesitaba no solo usar este patrón, sino poder administrar otras aplicaciones que lo usaban.

A. b.c. d

Incrementos: cuando
- d: corrección de errores
- c : mantenimiento, por ejemplo, mejora del rendimiento
- b : nuevas características
- a : cambio de arquitectura

El obligatorio es el más izquierdo, por ejemplo, si hay, por ejemplo, una nueva característica y un error corregido, solo tiene que incrementar b.

Es bastante popular en estos días usar el número de revisión de Subversion.

Los"números de versión" son un asunto de su sistema interno de control de versiones. Los números de lanzamiento son un asunto diferente (y deben MANTENERSE diferentes).

Apégate a una MAYOR simple.Sistema de liberación MENOR (como v1. 27), donde MAYOR es el nivel de compatibilidad (versión 2.x es incompatible con la versión 1 o al menos muy diferente.x) y MENORES son sus versiones de corrección de errores o mejoras menores. Siempre y cuando siga el formato X. Y, también puede usar otros sistemas como YEAR.MES (2009.12) o AÑO.RELEASE (2009.3). Pero probablemente sea mejor que te quedes con Major.MENOR a menos que tenga una buena razón para no hacerlo.

Definitivamente no use nada que no se ajuste al formato X. Y, ya que lo hará difícil para distribuciones, sitios web de anuncios, etc. trabajar contigo, y eso solo podría afectar seriamente la popularidad de tu proyecto.

Use ramas y etiquetas en su sistema de control de versiones (preferiblemente distribuido) para marcar números de versión internos específicos relacionados con las PRINCIPALES y MENORES respectivamente.

Y sí, 1.0 debería ser estable. Todas las versiones deben ser estables, a menos que estén marcadas como alfa, beta o RC. Utilice Alfas para conocido-roto-e-incompleto. Betas para conocido-roto. RCs para "pruébalo; probablemente verás cosas que nos perdimos". Cualquier cosa sin uno de estos debe (idealmente, por supuesto) ser probado, bien conocido, tener un manual actualizado, etc.

Si está en SVN, ¿por qué no usar el número de revisión SVN?

Si nos fijamos en la parte inferior derecha de esta página web, verá el número de versión Stack Overflow que es el número de revisión SVN.

El control de versiones depende de usted; pondría 1.0 en la primera versión en la que confiaba. Es posible que desee seguir rápidamente con otras versiones, ya que algunos proveedores de software han dado 1.0 una mala reputación.

Desea alguna forma de vincular el número de versión a la compilación exacta utilizada, pero probablemente desee que sea agradable y simple para sus usuarios finales. Considere usar números de versión estándar y etiquetar el repositorio SVN con el número de versión incluido.

Aunque simplemente ir con el número de revisión de Subversion es agradable y simple, elimina información del número de versión. Los usuarios podrían considerar esto una mala cosa.

Asumo que su aplicación web tendrá algún tipo de procedimiento de implementación, por lo que no cada revisión en Subversion se publica realmente. Dado que es imposible desde el" exterior " (desde la perspectiva del usuario) determinar cuándo se están haciendo las liberaciones, y cuántas revisiones sufrirá el código entre ellas, hace que los números casi al azar. Van a aumentar, y supongo que es posible suponer algún tipo de distancia de comparar dos revisiones, pero no mucho.

Los números de versión clásica tienden a "dramatizar" los lanzamientos, para que los usuarios puedan construir algún tipo de expectativa. Es más fácil pensar" Tengo la versión 1.0, ahora la versión 1.1 está agregando esto y aquello, eso suena interesante "que pensar" ayer corrimos ASÍ QUE revisión 2587, hoy es 3233, debe ser mucho mejor!".

Por supuesto, esta dramatización también se puede inflar, con las compañías eligiendo números de versión que están destinados a sonar más interesantes que los motivados por las diferencias reales en el producto, supongo que ir con los contadores de números de revisión esto un poco.

Esquema de la versión: [mayor].[menor].[devrel] [mark]
[mayor]: incremento si tienes un cambio drástico en el desarrollo.
[menor]: incremento si tiene un cambio menor en el desarrollo.
[devrel]: incrementa si tienes una corrección de error. Restablecer a cero si mayor++ o menor++.
[mark]: a, b o rc: a es una versión alfa, b es una versión beta y rc es una versión candidata. Tenga en cuenta que versiones como 1.3.57 a o 1.3.57 b o 1.3.57 rc es anterior a la versión 1.3.57. Inicio en 0.0.0.

Hemos pasado demasiado tiempo decidiendo cuándo incrementar la versión principal. Algunas tiendas rara vez lo harían por lo que tendría versiones como 1.25.3 y otros lo harían para siempre lanzamiento que le da 15.0

Me harté de eso y convencí a todos de que el número de lanzamiento principal es solo del año y el menor es solo un lanzamiento secuencial dentro del año. A los usuarios parecía gustarles y es una obviedad llegar a la próxima versión numero.

Año.Lanzar.build

• año = año en curso
• release = secuencia # de lanzamientos públicos con nueva funcionalidad-restablecer a 1 cada año
• build = incrementado para bug correcciones y versiones internas

EDITAR

* * Ahora esto fue para una aplicación interna que se mejoró continuamente * *

Esto probablemente no funcionaría para aplicaciones comerciales donde es importante tener lanzamientos importantes en diferentes épocas del año para el marketing y fines financieros.

Tengo muy poca experiencia en el área. Sin embargo, esto es lo que haría:

1. Elija un esquema para numerar las revisiones y apéguese a él. Sé consistente.
2. Cada cambio de versión debe representar un cambio significativo. Qué tan pequeño es un cambio significativo y los niveles de cambio que se reflejan en el número de versión dependen de usted.

Por supuesto, puede usar el número de revisión svn - - - como muchos otros han sugerido!!!

Espero que esto ayudar.

La razón por la que existe esta pregunta es porque no tenemos una sola forma acordada de administrar la configuración.

La forma en que me gusta hacer el número de versión es simplemente incrementar entero desde 1. No quiero un número de versión de varias partes que tendré que explicar o documentar. Y no quiero usar el número de rev de SVN, ya que requerirá alguna explicación también.

Necesitaría algunos scripts de liberación en la parte superior de SVN para hacer que esto suceda

Usamos una mayor simple.menor.julian_date sintaxis.

Donde;

• mayor: La primera versión es 1 y luego, cuando introduzcamos nuevas características importantes o cambios tan significativos que no sean compatibles con versiones anteriores, aumenta este número.
• minor - Las versiones de mayor hito. Para cada compilación impulsada por la producción, este número aumenta.
• julian_date - El Día Juliano la compilación fue empujada a QA.

Ejemplo de la primera versión enviada a QA en 1/15 is -> 1.0.015
Ejemplo de la primera versión empujada a Producción en 3/4 es - > 1.1.063

No es perfecto, pero es útil ya que empujamos compilaciones a QA casi diariamente.

Una buena información aquí:

Cuándo cambiar las Versiones de Archivo/Ensamblaje

En primer lugar, las versiones de archivo y las versiones de ensamblaje no tienen por qué coincidir entre sí. Recomiendo que las versiones de los archivos cambien con cada compilación. Pero, no cambie las versiones de ensamblado con cada compilación solo para que pueda notar la diferencia entre dos versiones del mismo archivo; use la versión de archivo para eso. Decidir cuándo cambiar las versiones de ensamblado requiere cierta discusión de los tipos de compilaciones a considere: envío y no envío.

Construcciones no relacionadas con el envío En general, recomiendo mantener las versiones de ensamblaje que no son de envío igual entre las compilaciones de envío. Esto evita problemas de carga de ensamblajes fuertemente nombrados debido a desajustes de versión. Algunas personas prefieren usar la política del editor para redirigir nuevas versiones de ensamblado para cada compilación. Sin embargo, no recomiendo eso para compilaciones que no sean de envío: no evita todos los problemas de carga. Por ejemplo, si un socio x copia tu app, puede que no sabe instalar la directiva del editor. Luego, su aplicación se romperá para ellos, a pesar de que funciona bien en su máquina.

Pero, si hay casos en los que diferentes aplicaciones en la misma máquina necesitan vincularse a diferentes versiones de su ensamblaje, recomiendo dar a esas versiones diferentes versiones de ensamblaje para que se pueda usar la correcta para cada aplicación sin tener que usar LoadFrom/etc.

Compilaciones de envío En cuanto a si es una buena idea cambiar esa versión para las compilaciones de envío dependen de cómo desee que funcione el enlace para los usuarios finales. ¿Quieres que estas construcciones estén lado a lado o en el lugar? Hay muchos cambios entre las dos versiones? ¿Van a romper algunos clientes? ¿Te importa que los rompa (o quieres forzar a los usuarios a usar tus actualizaciones importantes)? En caso afirmativo, debería considerar incrementar la versión del ensamblado. Pero, por otra parte, considere que hacer eso demasiadas veces puede ensuciar el disco del usuario con ensamblados obsoletos.

Cuando Cambia Las Versiones De Ensamblaje Para cambiar las versiones hardcoded a la nueva, recomiendo configurar una variable a la versión en un archivo de encabezado y reemplazar la codificación hardcoded en las fuentes con la variable. Luego, ejecute un preprocesador durante la compilación para colocar la versión correcta. Recomiendo cambiar las versiones justo después del envío, no justo antes, para que haya más tiempo para detectar errores debido al cambio.

O usar su número de versión 'thought' coma número de subversion.. z. B.:

1.0.101 / / revisión 101, versión

O 1.0.101-090303 // con fecha de lanzamiento, utilizo este