release - que - Obtener los números de versión del software correctos. v1.0.0.1
release management traduccion (16)
Creo que hay dos formas de responder a esta pregunta, y no son del todo elogiosas.
- Técnico: Incrementar versiones basadas en tareas técnicas. Ejemplo: D es el número de compilación, C es iteración, B es una versión menor, A es una versión mayor. Definir versiones menores y principales es realmente subjetivo, pero podría estar relacionado con cosas como cambios en la arquitectura subyacente.
- Marketing: Incremente las versiones según la cantidad de funciones "nuevas" o "útiles" que se le brinden a sus clientes. También puede vincular los números de versión a una política de actualización ... Los cambios en A requieren que el usuario adquiera una licencia de actualización, mientras que otros no.
La conclusión, creo, es encontrar un modelo que funcione para usted y sus clientes. He visto algunos casos en los que las versiones pares son publicaciones públicas y las versiones impares se consideran versiones beta o dev. He visto algunos productos que ignoran C y D todos juntos.
Luego está el ejemplo de Micrsoft, donde la única explicación racional para los números de versión para .Net Framework es que el Marketing estuvo involucrado.
Distribuyo software en línea y siempre me pregunto si existe una forma adecuada de definir mejor los números de versión.
Supongamos ABCD en las respuestas. ¿Cuándo aumenta cada uno de los componentes?
¿Utiliza algún otro truco de número de versión, como D mod 2 == 1, significa que es solo un lanzamiento interno?
¿Tiene versiones beta con sus propios números de versión o tiene versiones beta por número de versión?
El único uso que he hecho del número de versión fue para que un cliente pudiera decirme que está usando la versión 2.5.1.0 o lo que sea.
Mi única regla está diseñada para minimizar los errores al informar ese número: los cuatro números tienen que ser de 1 dígito solamente .
1.1.2.3
está bien, pero
1.0.1.23
no es. Es probable que los clientes denuncien ambos números (verbalmente, al menos) como "uno-uno-dos-tres".
Los números de compilación de incremento automático a menudo dan como resultado números de versión como
1.0.1.12537
lo cual tampoco ayuda mucho.
En las últimas seis versiones principales, hemos utilizado M.0.mb donde M es la versión principal, m es la versión menor yb es el número de compilación. Las versiones liberadas incluían 6.0.2, 7.0.1, ..., hasta 11.0.0. No preguntes por qué el segundo número es siempre 0; Lo he preguntado varias veces y nadie sabe realmente. No hemos tenido un cero distinto desde que se lanzó el 5.5 en 1996.
Estoy empezando a gustarme el año. Libere la convención [.Build] que usan algunas aplicaciones (por ejemplo, Perforce). Básicamente solo dice el año en que lanzas y la secuencia dentro de ese año. Entonces, 2008.1 sería la primera versión, y si publicara otra uno meses o tres más tarde, iría a 2008.2.
La ventaja de este esquema es que no hay una "magnitud" implícita de publicación, en la que se entra en discusiones sobre si una característica es lo suficientemente importante como para justificar un aumento de versión mayor o no.
Un extra opcional es etiquetar en el número de compilación, pero eso tiende a ser solo para fines internos (por ejemplo, agregado al archivo EXE / DLL para que pueda inspeccionar el archivo y asegurarse de que la compilación correcta esté allí).
La gente tiende a querer hacer esto mucho más difícil de lo que realmente necesita ser. Si su producto tiene solo una sola sucursal de larga vida, solo nombre las versiones sucesivas por su número de compilación. Si tienes algún tipo de "correcciones de errores menores son gratuitas, pero tienes que pagar por nuevas versiones importantes", utiliza 1.0, 1.1 ... 1.n, 2.0, 2.1 ... etc.
Si no puede determinar de inmediato qué representan A, B, C y D en su ejemplo, entonces obviamente no los necesita.
Normalmente utilizo D como contador de compilación (incremento automático por compilador) Incremento C cada vez que se lanza una compilación a "público" (no todas las compilaciones se publican) A y B se usan como número de versión mayor / menor y se modifican manualmente.
Nuestra política:
- A - Cambios o adiciones significativas (> 25%) en la funcionalidad o la interfaz.
- B: pequeños cambios o adiciones en la funcionalidad o la interfaz.
- C - cambios menores que rompen la interfaz.
- D: arreglos para una construcción que no cambia la interfaz.
Para el desarrollo interno, utilizamos el siguiente formato.
[Program #] . [Year] . [Month] . [Release # of this app within the month]
Por ejemplo, si estoy lanzando la aplicación número 15 hoy, y esta es la tercera actualización de este mes, entonces mi versión será
15.2008.9.3
No es totalmente estándar, pero es útil para nosotros.
Un esquema bueno y no técnico simplemente usa la fecha de compilación en este formato:
YYYY.MM.DD.BuildNumber
Donde BuildNumber es un número continuo (lista de cambios) o simplemente comienza de nuevo en 1 cada día.
Ejemplos: 2008.03.24.1 o 2008.03.24.14503
Esto es principalmente para lanzamientos internos, los lanzamientos públicos verían la versión impresa como 2008.03 si no se lanza más de una vez al mes. Las versiones de mantenimiento se marcan como 2008.03a 2008.03b y así sucesivamente. Raramente deberían pasar por "c", pero si lo hace es un buen indicador de que necesita un mejor control de calidad y / o procedimientos de prueba.
Los campos de versión que comúnmente ve el usuario deben imprimirse en un formato amigable de "marzo de 2008", reserve la información más técnica en el diálogo Acerca de o en los archivos de registro.
La mayor desventaja: simplemente compilar el mismo código en otro día podría cambiar el número de versión. Pero puede evitar esto usando la lista de cambios de control de versiones como último número y comprobando en contra de eso para determinar si también se debe cambiar la fecha.
Yo uso VRM, por ejemplo 2.5.1
Los cambios V (versión) son una gran reescritura
Los cambios R (revisión) son nuevas características significativas o correcciones de errores
Los cambios de M (modificación) son correcciones menores de tipo bux (errores tipográficos, etc.)
A veces uso un número de confirmación SVN al final también.
Todo es realmente subjetivo al final del día y simplemente depende de usted / su equipo.
Solo eche un vistazo a todas las respuestas, todas muy diferentes.
Personalmente uso Major.Minor.*.* - Donde Visual Studio rellena automáticamente el número de revisión / compilación. Esto se usa donde yo también trabajo.
En mi opinión, casi cualquier esquema de números de publicación puede funcionar más o menos bien. El sistema en el que trabajo usa números de versión como 11.50.UC3, donde la U indica Unix de 32 bits, y el C3 es un número de revisión menor (fixpack); otras letras se usan para otros tipos de plataformas. (No recomendaría este esquema, pero funciona).
Hay algunas reglas de oro que hasta ahora no se han establecido, pero que están implícitas en lo que la gente ha discutido.
- No libere la misma versión dos veces: una vez que la versión 1.0.0 se haya lanzado a nadie, nunca podrá volver a publicarse.
- Los números de versión deberían aumentar monótonamente. Es decir, el código en la versión 1.0.1 o 1.1.0 o 2.0.0 siempre debe ser posterior a la versión 1.0.0, 1.0.9 o 1.4.3 (respectivamente).
Ahora, en la práctica, las personas tienen que liberar arreglos para versiones más antiguas, mientras que las versiones más nuevas están disponibles; consulte GCC, por ejemplo:
- GCC 3.4.6 se lanzó después de 4.0.0, 4.1.0 (y AFAICR 4.2.0), pero continúa la funcionalidad de GCC 3.4.x en lugar de agregar las funciones adicionales agregadas a GCC 4.x.
Entonces, tienes que construir tu esquema de numeración de versiones cuidadosamente.
Otro punto en el que creo firmemente:
- El número de versión de lanzamiento no está relacionado con la numeración de la versión del sistema CM (VCS), a excepción de los programas triviales. Cualquier pieza seria de software con más de un archivo fuente principal tendrá un número de versión no relacionado con la versión de un solo archivo.
Con SVN, puede usar el número de versión de SVN, pero probablemente no, ya que cambia de manera impredecible.
Para las cosas con las que trabajo, el número de versión es una decisión puramente política.
Por cierto, sé que el software pasó por versiones de la versión 1.00 a la 9.53, pero luego cambió a 2.80. Eso fue un gran error, dictado por el marketing. De acuerdo, la versión 4.x del software es / estaba obsoleta, por lo que no generó confusión de inmediato, pero la versión 5.x del software todavía está en uso y se vendió, y las revisiones ya llegaron a 3.50. Estoy muy preocupado por lo que mi código tiene que funcionar con el 5.x (estilo antiguo) y el 5.x (estilo nuevo) va a funcionar cuando se produce el conflicto inevitable. Supongo que tengo que esperar que se dediquen diligentemente a cambiar a 5.x hasta que el antiguo 5.x realmente esté muerto, pero no soy optimista. También utilizo un número de versión artificial, como 9.60, para representar el código 3.50, de modo que pueda hacer una prueba if VERSION > 900 , en lugar de tener que hacerlo: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400) , donde represento la versión 9.00 por 900. Y luego está el cambio significativo introducido en la versión 3.00.xC3 - mi esquema no puede detectar cambios en el nivel de lanzamiento menor ... refunfuñar ... refunfuñar ...
NB : Eric Raymond proporciona el HOWTO de práctica de liberación de software, que incluye la sección (vinculada) sobre lanzamientos de nombres (numeración).
En esta nota técnica de Apple se describe un buen esquema de control de versiones fácil de usar que se originó en el viejo Mac OS: http://developer.apple.com/technotes/tn/tn1132.html
Me gusta Year.Month.Day. Entonces, v2009.6.8 sería la "versión" de esta publicación. Es imposible de duplicar (razonablemente) y es muy claro cuando algo es una versión más reciente. También puedes soltar los decimales y hacerlo v20090608.
En el caso de una biblioteca, el número de versión le informa sobre el nivel de compatibilidad entre dos versiones y, por lo tanto, qué tan difícil será una actualización.
Una versión de corrección de errores necesita preservar la compatibilidad binaria, fuente y serialización.
Los lanzamientos menores significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de la fuente.
Los números de versión principales pueden romper las tres formas.
Escribí más sobre la razón de ser aquí .
En el mundo de Github, se ha vuelto popular seguir las especificaciones de "semver" de Tom Preston-Werner para los números de versión.
De http://semver.org/ :
Dado un número de versión MAJOR.MINOR.PATCH, incremente el:
Versión PRINCIPAL cuando realiza cambios incompatibles de API, versión MINOR cuando agrega funcionalidad de una manera compatible con versiones anteriores y versión PATCH cuando realiza correcciones de errores compatibles con versiones anteriores. Se encuentran disponibles etiquetas adicionales para los metadatos preliminares y de compilación como extensiones del formato MAJOR.MINOR.PATCH.