Fecha como número de versión del software

Los desarrolladores de software generalmente no usan la fecha como número de versión, aunque el formato AAAAMMDD (o sus variaciones) parece lo suficientemente sólido como para usarlo. ¿Hay algo malo con ese esquema? ¿O se aplica solo a 'tipos' limitados de software (como las producciones internas)?

Esto es algo que tendrá que observar desde un par de ángulos diferentes, ya que debe tener en cuenta las necesidades del usuario, así como las necesidades del software y los desarrolladores.

En general, a sus clientes no les importará mucho cuál será el número de versión del software siempre que sepan que están ejecutando algo más nuevo (es decir, el Producto 2012 es más nuevo que el Producto 2010) y que lo saben. está actualizado si hay parches que se pueden implementar (es decir, Producto 2012, Actualización 10). Como tal, desde el punto de vista de la marca del cliente, tiendo a preferir una versión con nombre (por ejemplo, Windows XP, Windows Vista) seguida de una secuencia estricta de parches que los usuarios pueden instalar.

Dicho esto, sin embargo, escribir software que verifique las cosas que son fáciles para el usuario tiende a hacer que el código oculto sea mucho más difícil de escribir. Por lo tanto, tiendo a preferir el Major.Minoresquema de versión simple aunque solo sea porque puede hacer una comparación de números simple para verificar que algo esté actualizado como en lo siguiente:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Sin embargo, para poner esto en un poco de contexto, generalmente no me importa qué tan grande se vuelve el número menor (es decir, 1.1024), lo que permite que el sistema anterior continúe ejecutándose con éxito. En general, los números de revisión solo son de interés para el desarrollo interno y en realidad ni siquiera los he visto afectar mucho más allá de darles un número adicional para seguir.

Sin embargo, los dos esquemas anteriores en realidad solo no se aplican a entornos en los que se usa la implementación continua (es decir, Stack Exchange), que es donde tiendo a preferir algún tipo de fecha seguida de un número de revisión que parece usarse en Stack Exchange sitios. El razonamiento de esto es que las versiones van a cambiar con demasiada frecuencia en el entorno de implementación continua y es posible que haya varias versiones del código en el mismo día, lo que justifica el número de revisión y la fecha actual es tan buena como cualquiera para romper cosas fuera aún más. En teoría, podría usar el número de revisión para todo, pero el uso de la fecha actual le permite realizar un seguimiento interno de los principales hitos que podrían hacer que las cosas sean un poco más fáciles de discutir.

El problema con el uso de una fecha es que las especificaciones se escriben contra los números de conteo en lugar de una fecha de vencimiento.

"Esta parte de la funcionalidad debe estar en la versión 1. La otra parte de la funcionalidad debe estar en la versión 2."

No puede hacer referencia a una fecha en las especificaciones, ya que podría perderse la fecha de lanzamiento.

Si no tiene un proceso tan formal que necesita diferentes versiones identificadas de antemano, usar fechas está bien; no necesita agregar otro número a la mezcla.

Es poco probable que los números de versión contengan fechas, ya que su contexto está vinculado a las especificaciones.
Números de compilación es probable que contienen fechas, desde su contexto está ligado a la acumulación cuando se llevó a cabo.

Aunque este enfoque tiene los beneficios que usted describió, existen ciertos inconvenientes si usa la fecha como número de versión:

• Las versiones basadas en fechas son planas. Con v2.1.3 puede ver el número de versión, el número de sub-versión y el número de sub-sub-versión. Con 20110119 solo puede ver cuándo se escribió. Usted podría agrupar sus versiones basadas en fechas por mes, pero todavía no te dice nada. Podrías tener varios meses lentos de corrección de errores pequeños y luego dos semanas de codificación pesada que resultaría en una versión importante. Las fechas no te dicen eso, los números de versión regulares sí.

• Si realmente necesita cambiar la versión a diario y posiblemente el número de publicación, puede indicar que no tiene un proceso de publicación adecuado, sino que todos cambian enormemente las cosas y las promueven a los servidores de producción cuando lo deseen. Si es así, tiene un problema con el proceso, y el uso de un esquema de número de versión diferente no lo resolverá.

Las versiones se utilizan a menudo para transmitir información sobre cuán diferente es una versión particular del software de la anterior. Entonces, por ejemplo, si actualiza de 1.0 a 2.0 de Acme, esa es una actualización importante, en teoría con cambios importantes.

Una actualización de 1.0 a 1.1, por otro lado, es una actualización menor y en teoría conlleva cambios menores, incrementales y correcciones de errores.

Esto sería difícil de representar en un formato de fecha, aunque podría usar una mezcla. Por ejemplo, v1.0.YYYY.MMDD

Sin repetir buenas ideas de otras respuestas, tengo un problema en mente que aún no se abordó.

Si sucede una bifurcación, entre una versión anterior para compatibilidad con versiones anteriores y una nueva versión para una modernización incompatible, no puede distinguirlos a través de números de versión.

Por ejemplo, el kernel de Linux se bifurcó alrededor del año 2000 en la antigua rama 2.4.x, que probablemente todavía se admite hoy y cuenta como 2.4.199, mientras que la nueva versión ha sido 2.6 durante muchos, muchos años y es 2.6.32 para sistemas más antiguos, pero 3.2 para los núcleos más nuevos.

Si tiene documentación sobre sus lanzamientos, duplicará la información y le dirá a la gente que la versión 20120109 llegó en 2012 al 01/09. Mh Pero qué, si hay una detección de errores de último momento, y un lanzamiento se retrasa por una semana, pero la documentación, donde se menciona el nombre, ya está lista, tal vez impresa, la información de prensa está fuera, etc. Ahora tiene una discrepancia que es problemática si la versión 20120109 llegó el 13/01/2012.

En SQL, a menudo se ha discutido la cuestión de si las ID deben llevar información semántica, y el resultado es siempre: ¡evítelo como el infierno! Estás creando una dependencia innecesaria. No puede ser de beneficio.

Ubuntu con su esquema 04/10 tuvo su problema en 2006, cuando la versión 6.04 se retrasó y se convirtió en 6.06. ¡En el año 3000 pronto habrá el próximo problema! :)

Hay muchos paquetes de software que sí usan la fecha como versión. Ubuntu viene a la mente, donde su versión es YY.MM. Y los números de compilación para los productos de Microsoft Office también son una codificación de la fecha de compilación. Jeff Atwood escribió una publicación en el blog Coding Horror sobre la numeración de versiones , incluida esta recomendación:

Siempre que sea posible, use fechas simples en lugar de números de versión, particularmente en los nombres públicos de los productos. Y si absolutamente debe usar números de versión internamente, hágalos de todas formas: asegúrese de codificar la fecha de la compilación en algún lugar de su número de versión.

En mi opinión, no importa mientras seas constante y puedas pasar de un número de versión de compilación (lo que sea) y recordar todos los artefactos que ingresaron a esa compilación desde tu sistema de control de versiones. Los usuarios generalmente no se preocupan por la información de la versión, sino por la funcionalidad proporcionada por el sistema. La información de versiones solo tiene un valor real para los desarrolladores.

Utilice el control de versiones semántico: de esa manera, tendrá una idea del tipo de cambios que se realizan entre versiones sin tener que inspeccionar el código en sí: http://semver.org/

Usar números de versión es una forma de mostrar cuán GRANDE es el cambio

Por ejemplo, 2.4.3 puede significar que la versión 2 es el cambio principal en todo el sistema. .4 es una actualización menor. y el último .3 es una pequeña corrección de errores para esa versión. De esa manera es fácilmente reconocible cuánto ha cambiado entre cada versión.

Dicho esto, todavía veo que muchas personas usan fechas o números de revisión de SCM como números de versión, siempre que tenga alguna forma de rastrear las notas de soporte y la documentación de lo que estaba dentro del alcance de ese lanzamiento, no hay ningún problema real.

Algunas buenas respuestas aquí ya, pero me gustaría señalar un caso en el que el uso de fechas tiene mucho sentido: pequeñas bibliotecas o fragmentos de código donde es probable que el código se actualice con frecuencia, pero en pequeños bits sin una versión única que difiera dramáticamente con la anterior uno.

En otras palabras, estoy hablando de situaciones en las que no hay un "número de versión" real, sino básicamente una especie de volcado de repositorio casi diario.

Cuando me encuentro con este tipo de cosas, generalmente doy la bienvenida a la elección, ya que es más útil para mí saber que estoy usando un script / lib relativamente actual en lugar de una versión específica.

Las fechas como número de versión son buenas para el marketing. Si las personas usan "Windows NT 5.0", es posible que no se den cuenta de que está obsoleto. Pero si las personas todavía usan "Windows 2000", sabrán instantáneamente que es un sistema operativo de 12 años y se les animará a actualizar.

Sin embargo, hace que sea más difícil distinguir entre actualizaciones "mayores" y "menores".

Problema con el uso de fechas como números de versión

Las respuestas aquí son buenas, pero no vi a nadie abordar esta preocupación con el uso de fechas: el usuario no puede determinar con qué frecuencia se han realizado modificaciones.

Lo que intento decir es que puedo decir que Windows 3.1 y Windows 7 están muy separados ... y tal vez son incompatibles. Windows 95 y Windows 2000 no me dicen nada más que el año en que se presentó el producto.

Por ejemplo, con Python, sé que la versión 2.7.2 ha evolucionado desde 2.4.6. Si busco más, veo que la versión 2.4.6 se lanzó el 19 de diciembre de 2008; y que la versión 2.7.2 se lanzó el 11 de junio de 2011. A partir de esto, puedo formar una opinión sobre la estabilidad (es decir, la frecuencia de lanzamiento) de un producto.

Si, en cambio, Python había usado fechas de lanzamiento, no puedo saber cómo podrían conectarse estos productos. Se produciría más confusión, porque Python 3.1.4 también se lanzó el 11 de junio de 2011 (lo mismo que Python 2.7.2).

En resumen, no creo que, por sí mismo, el versionado de fechas sea valioso.

No me gusta esta idea, por razones ya descritas por otros. Simplemente use el esquema major.minor.bugfix: hay una razón por la cual la mayoría de las personas lo hacen de esta manera.

Pero hagas lo que hagas: elige un esquema de nomenclatura de versión y cúmplelo . No lo haga como Windows, donde cambian el esquema con cada lanzamiento. Y no lo haga como Android, donde cada versión tiene un número de versión API (8), un número de versión destinado a marketing (2.2) y un nombre estúpido (Froyo).

Fecha como versión

Si su producto no se vende, simplemente usar la fecha está bien y probablemente sea útil. Si lo vende y actualiza a los clientes, ellos quieren comprar un modelo con un conjunto específico de características. Es mucho más fácil venderlos en una actualización si este modelo tiene un nombre claro, en realidad no importa de qué se trate, pero por ejemplo, nadie realmente compra el Ford Car del 20 de enero de 2012, quieren el modelo Kia. Lo mismo es cierto para el software. Dar un nombre y una versión de modelo rígidos significa que tiene características diferentes a las anteriores. Para mí, solo una cita no hace eso, dice que lo hice en ese momento, no podría tener nuevas características.

Esquema que usamos

No afirmé que nuestro sistema crea una marca clara como la anterior. Ahora usamos un esquema de cuatro partes. Un número de versión, estado, la fecha y una suma de verificación.

1200_GLD_120120_F0D1

Esto puede parecer excesivo, pero nos permite tener varias versiones de la compilación para la versión 1200 que nuestros ingenieros pueden usar y diferenciamos entre ellos por fecha. El estado le dice a la gente si es una versión de prueba interna, un parche de cliente o una versión dorada. La suma de verificación es nueva, permite que un ingeniero o cliente verifique que realmente hayan descargado la correcta de nuestra distribución.

Entonces podríamos tener una secuencia de

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Normalmente solo nos referimos a los números de versión principales para el cliente, es decir, "12", pero un cliente obtendrá la última versión dorada de 12, es decir, 1200_GLD_120120_F0D1, a menos que necesite la corrección.

Digamos que algunos clientes usan la versión dos de su producto, y algunos han actualizado a la versión tres, y esa actualización no es una decisión tomada a la ligera.

Digamos que la última versión de la versión dos es 2.3.2, y la versión tres está en 3.0.3. Ahora encuentra una vulnerabilidad que absolutamente necesita ser reparada, por lo que libera 2.3.3 y 3.0.4 el mismo día. ¿Puedes ver cómo la fecha de lanzamiento es totalmente irrelevante? Es posible que haya dejado de trabajar en la versión dos en 2013 y solo haya lanzado algunas correcciones de errores esenciales desde entonces. La fecha es irrelevante en comparación con el número de versión.

Creo que funciona muy bien. Lo uso para algún software interno (aaaa.mm.dd) y para algún software de código abierto que publiqué.

Puede que no funcione en todos los casos.

Técnicamente, no puede usar la fecha para el número de versión, pero podría mostrar el número de fecha para el cliente. Por ejemplo, macOS 16.7.23 --- significa que: 23/7/2016

Creo que la tecnología no es el problema, el problema es cómo se siente. Si usa un número de fecha que podría hacer que el software viva, viva, como un hombre cuyo número de cumpleaños. Cada año que estamos creciendo, lo mismo que el software sigue creciendo.

El número del edificio se parece a la máquina, la máquina, sin vida, sin vida.