Mejor práctica: versiones de software [cerrado]


211

¿Existe alguna directriz o práctica recomendada estándar para versionar un software que desarrolle en su tiempo libre para divertirse, pero que sin embargo será utilizado por algunas personas? Creo que es necesario versionar dicho software para que sepas con qué está hablando la versión uno (por ejemplo, para la corrección de errores, soporte, etc.).

¿Pero dónde empiezo el versionado? 0.0.0? o 0.0? ¿Y luego cómo incrementar los números? lanzamiento principal ¿cambio menor? ¿y no debería comprometerse con un sistema de control de versiones ser otra versión? ¿O es solo para versiones que se utilizan de manera productiva?


2
¿Qué hace su herramienta de control de código fuente? Usted debe usar una. Cual estas usando?
S.Lott

3
Llego un poco tarde ... pero un engañado de stackoverflow.com/questions/615227/how-to-do-version-numbers
derivación


1
@DaveGregory tiene una respuesta no basada en opiniones a la pregunta. Ese enlace semver.org describe una versión semántica en detalle. El mismo esquema es utilizado comúnmente por la mayoría de los proyectos de Google, incluido Android. Además, en Tom Preston-Werner podemos encontrar una voz tan creíble como cualquiera sobre este tema.
Rahul Murmuria

Respuestas:


125

Debe comenzar con la versión 1, a menos que sepa que la primera versión que "lanza" está incompleta de alguna manera.

En cuanto a cómo incrementar las versiones, depende de usted, pero use la numeración de compilación mayor, menor, como guía.

No es necesario tener todas las versiones que se comprometen al control de origen como otra versión; pronto tendrá un número de versión muy grande. Solo necesita incrementar el número de versión (de alguna manera) cuando lanza una nueva versión al mundo exterior.

Entonces, si realiza un cambio importante, pase de la versión 1.0.0.0 a la versión 2.0.0.0 (cambió de WinForms a WPF, por ejemplo). Si realiza un cambio menor, muévase de 1.0.0.0 a 1.1.0.0 (agregó soporte para archivos png). Si realiza un cambio menor, pase de 1.0.0.0 a 1.0.1.0 (solucionó algunos errores).

Si realmente desea obtener detalles, use el número final como el número de compilación que aumentaría para cada registro / confirmación (pero creo que eso va demasiado lejos).


Tengo una pregunta sobre su respuesta: si estoy trabajando con la versión 1.0.0.0 y estoy implementando un cambio menor, menor o grande y también quiero usar el número de compilación. ¿En qué número de versión debo agregar la versión de compilación? Imagínese, me estoy mudando de 1.0.0.0 a 1.0.1.0. ¿En qué número tengo que poner el número de compilación? Y, en la versión final, ¿tendrá también un número de compilación en su número de versión (1.0.1.234)?
VansFannel

@VansFannel, esperaría que el número de compilación se restablezca a 0 cada vez que suba cualquier número superior.
Jeffrey Kemp

@JeffreyKemp Sí, creo que sí. Pero en el trabajo usamos el número del día del año y no me gusta.
VansFannel

Yuck, tampoco me gustaría eso :(
Jeffrey Kemp

2
También se debe tener en cuenta que los cambios en las versiones principales generalmente no son compatibles con versiones anteriores. Los incrementos en la versión menor son compatibles con versiones anteriores dentro de la versión principal. El cambio de una implementación MySQL codificada a una implementación genérica podría ser una versión principal debido al tamaño del cambio, pero también podría considerarse un cambio de características (menor) porque sigue siendo compatible con versiones anteriores.
ACS


42

Básicamente sigo este patrón:

  • comenzar desde 0.1.0

  • cuando esté listo, ramifico el código en el repositorio de origen, etiqueto 0.1.0 y creo la ramificación 0.1.0, la cabecera / troncal se convierte en una instantánea de 0.2.0 o algo similar

  • Agrego nuevas funciones solo al tronco, pero las correcciones de backport a la rama y con el tiempo libero de ella 0.1.1, 0.1.2, ...

  • Declaro la versión 1.0.0 cuando el producto se considera completo y no tiene grandes deficiencias.

  • a partir de entonces, todos pueden decidir cuándo aumentar la versión principal ...


¿Qué sucede si tengo más de 9 funciones, puedo escribir x.20.0?
Jemshit Iskenderov

@JemshitIskenderov Por supuesto que puedes.
Pavel S.

35

Yo uso esta regla para mis aplicaciones:

xyz

Dónde:

  • x = número de versión principal, 1- ~.
  • y = número de función, 0-9. Aumente este número si el cambio contiene nuevas características con o sin corrección de errores.
  • z = número de revisión, 0- ~. Aumente este número si el cambio solo contiene correcciones de errores.

Ejemplo:

  • Para una nueva aplicación, el número de versión comienza con 1.0.0.
  • Si la nueva versión contiene solo correcciones de errores, aumente el número de revisión para que el número de versión sea 1.0.1.
  • Si la nueva versión contiene nuevas funciones con o sin corrección de errores, aumente el número de función y restablezca el número de revisión a cero para que el número de versión sea 1.1.0. Si el número de función llega a 9, aumente el número de versión principal y restablezca la función y el número de revisión a cero (2.0.0, etc.)

36
Sugeriría usar este esquema sin pasar 9 -> 0 en el número de "función" / "revisión", ¡simplemente vaya al 10! 10 actualizaciones menores siguen siendo actualizaciones menores si se emitieron de forma incremental, no hay nada de malo en 1.10.0 o 1.1.10.
ttarik

44
..y seguir subiendo. ¿Qué sucede si realmente tiene 23 características para implementar antes de la v.2? ¿Y luego 30 correcciones de errores en esa última característica? Tendría la versión 1.23.30. Los lanzamientos de versiones principales son grandes conceptos abstractos con ciertos hitos, sin necesidad de adherirse arbitrariamente a las reglas de conteo decimal.
brianclements

11

Usamos abcd donde

  • a - mayor (incrementado en la entrega al cliente)
  • b - menor (incrementado en la entrega al cliente)
  • c - revisión (incrementada en versiones internas)
  • d - construcción (incrementada por control de crucero)

5

Otro ejemplo más del A.B.Cenfoque es el Eclipse Bundle Versioning . Los paquetes de Eclipse tienen más bien un cuarto segmento:

En Eclipse, los números de versión se componen de cuatro (4) segmentos: 3 enteros y una cadena nombrada respectivamente major.minor.service.qualifier. Cada segmento captura una intención diferente:

  • el segmento principal indica rotura en la API
  • el segmento menor indica cambios "visibles externamente"
  • el segmento de servicio indica correcciones de errores y el cambio de flujo de desarrollo
  • el segmento calificador indica una compilación particular

5

También existe el esquema de la fecha de versiones , por ejemplo: YYYY.MM, YY.MM,YYYYMMDD

Es bastante informativo porque una primera mirada da una impresión sobre la fecha de lanzamiento. Pero prefiero el esquema xyz, porque siempre quiero saber el punto exacto de un producto en su ciclo de vida (Major.minor.release)


2

La respuesta básica es "depende".

¿Cuál es su objetivo en el versionado? Muchas personas usan version.revision.build y solo anuncian version.revision al mundo, ya que es una versión de lanzamiento en lugar de una versión de desarrollo. Si utiliza la 'versión' de check-in, rápidamente encontrará que sus números de versión se hacen más grandes.

Si está planeando su proyecto, entonces incrementaría la revisión de las versiones con cambios menores y la versión de incremento para las versiones con cambios importantes, correcciones de errores o funcionalidad / características. Si está ofreciendo versiones de tipo de compilación beta o nocturna, extienda el control de versiones para incluir la compilación e incremente eso con cada versión.

Aún así, al final del día, depende de usted y tiene que tener sentido para usted.


2

Como dice Mahesh: usaría el tipo de versiones xyz

x - versión principal y - versión menor z - número de compilación

es posible que desee agregar una fecha y hora, tal vez en lugar de z.

Incrementa la versión menor cuando tiene otra versión. La versión principal probablemente se mantendrá 0 o 1, usted cambia eso cuando realmente realiza cambios importantes (a menudo cuando su software está en un punto donde no es compatible con versiones anteriores, o si cambió todo su marco)


2

Sabes que siempre puedes verificar qué están haciendo los demás. El software de código abierto tiende a permitir el acceso a sus repositorios. Por ejemplo, puede apuntar su navegador SVN a http://svn.doctrine-project.org y echar un vistazo al sistema de versiones utilizado por un proyecto real.

Números de versión, etiquetas, todo está ahí.


2

Seguimos un enfoque abc como:

incremento 'a' si hay algunos cambios importantes ocurridos en la aplicación. Al igual que actualizamos la aplicación .NET 1.1 a .NET 3.5

incremento 'b' si hay algunos cambios menores, como cualquier CR nuevo o Mejora implementado.

incremento 'c' si hay algunos defectos corregidos en el código.


0

Empiezo a versionar en el segmento más bajo (sin revisión). No limito este segmento a 10. A menos que esté rastreando compilaciones, solo necesita decidir cuándo desea aplicar un incremento. Si tiene una fase de control de calidad, entonces podría ser donde aplique un incremento al segmento más bajo y luego la siguiente división hacia arriba cuando pase el control de calidad y se libere. Deje el segmento superior para cambios de comportamiento / interfaz de usuario principales.

Si eres como yo, lo convertirás en un híbrido de los métodos para que coincida con el ritmo de la progresión de tu software.

Creo que el patrón más aceptado es abc o abcd, especialmente si tiene QA / Compliance en la mezcla. He tenido tanto problema con la fecha como parte regular de las versiones que lo dejé para la corriente principal.

No sigo las compilaciones, por lo que me gusta usar el patrón abc a menos que se trate de una revisión. Cuando tengo que aplicar una revisión, aplico el parámetro d como una fecha con hora. Adopté el parámetro de tiempo como d porque siempre existe el potencial de varios en un día cuando las cosas realmente explotan en la producción. Solo aplico el segmento d (AAAAMMDDHHNN) cuando diverjo para un arreglo de producción.

Personalmente, no me opondría a un esquema de software de va.b revc donde c es AAAAMMDDHHMM o AAAAMMDD.

Todo eso dicho. Si solo puede enganchar una herramienta para configurarla y ejecutarla, evitará el dolor de cabeza de tener que analizar la faceta de la opinión sobre el control de versiones y simplemente puede decir "usar la herramienta" ... porque todos en el proceso de desarrollo suelen ser tan obedientes .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.