2010-05-07 9 views

Respuesta

54

Realmente difiere de un proveedor a otro. Lo más común es que son (en orden):

  • mayor número de release
  • versión menor número
  • Número de Publicación
  • Mantenimiento (sólo correcciones de errores)
  • Si utilizan en absoluto: el número de compilación (o revisión de control de origen número)

1.7.1.0 sería esta la primera versión de mantenimiento para la versión 1.7 del producto.

Incluso es difícil definir cuál es la diferencia entre una versión mayor y una versión menor. Los lanzamientos principales normalmente incluyen nuevas características significativas. O el vendedor simplemente quiere que la gente pague por el producto nuevamente. Las versiones menores pueden incluir correcciones y nuevas características, pero generalmente nada innovador.

Algunas empresas usan el bit de lanzamiento menor para diferenciar entre las versiones alpha/beta y las versiones finales. Los números impares son pre-lanzamientos e incluso los números son finales. 1.7 sería una versión beta de una próxima versión 1.8. Sin embargo, este hábito se está volviendo cada vez menos común.

Incremento de números de compilación con cada versión, sin importar cuán pequeños sean los cambios. Se incrementa automáticamente por el proceso de compilación, cada vez que se ejecuta. Muchas compilaciones nunca se publican, pero pueden ayudar a administrar el ciclo de vida del software, al facilitar al QA la identificación exclusiva de una versión del software.

+1

Parece que Mircrosoft lo hace como, Parte principal, Parte secundaria, Parte de compilación, Parte de revisión como se describe en esta [página] (https://msdn.microsoft.com/en-gb/library/ms973869.aspx?f=255&MSPPError = -2147217396). – Lsakurifaisu

19

Normalmente estos son <Major.Minor.Revision.Build>.

Dónde:

  • Major es una importante actualización de software
  • menor es una pequeña actualización del software del
  • La revisión es cualquier cambio realizado (correcciones de errores, pequeños cambios)
  • Construir número (normalmente un incremento automático si se usa)

En su ejemplo (1.7.1.0):

  • versión principal 1
  • tenía 7 actualizaciones menores
  • primera revisión/corrección de errores
  • Sin número de compilación
+2

No estoy seguro de que sea normal ya que Microsoft tiene los últimos dos revertidos. –

1

Otro método ampliamente utilizado es tener un número de compilación incremental. Sin ninguna correlación con la llamada "versión".

"Versión" es más interesante para los consumidores que desean saber que este es un producto nuevo, por lo tanto, solo le da un nombre a cada publicación.

Pero para usos internos y una fácil referencia del producto y su versión probada controlada por el código fuente, un número de compilación incremental simple podría ser más conveniente.

3

Cada proyecto elige su propia convención. Como otros han señalado, una convención común es "Major.Minor.Revision.Build"

Un par de mis favoritos son:

Ubuntu versions son "año.mes.día". Por ejemplo, 10.04 fue lanzado en abril de 2010.

TeX versions son teóricamente sólo bux-correcciones para siempre, por lo que sus versiones se acercan asintóticamente pi (por ejemplo 3,1415926)

+1

Haha, no sabía acerca de los números de versión de TeX. Por otra parte, solo he utilizado LaTeX, y de manera muy limitada :) – Thorarin

+0

Vale la pena señalar que cada vez más proyectos están cambiando al mes o la fecha de publicación últimamente porque la tendencia es para lanzamientos frecuentes y los números de versión son cada vez mayores. –

Cuestiones relacionadas