fecha como número de versión del software

39

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

    
pregunta Donotalo 19.01.2012 - 12:55

16 respuestas

14

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

En general, a sus clientes no les va a importar mucho 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 eso saben que está actualizado si hay parches que se pueden implementar (por ejemplo, Producto 2012, Actualización 10). Como tal, desde el punto de vista de la marca del cliente, tiendo a preferir las versiones con nombre (por ejemplo, Windows XP, Windows Vista) seguidas por una secuencia estricta de parches que los usuarios pueden instalar.

Dicho esto, sin embargo, escribir software que comprueba cosas que son fáciles para el usuario tiende a hacer que el código bajo el capó sea mucho más difícil de escribir. Por lo tanto, tiendo a preferir el esquema simple de versión Major.Minor solo porque puede hacer una comparación simple de números para verificar que algo esté actualizado, como se muestra a continuación:

// 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 cuán grande sea el número menor (es decir, 1.1024) que permite que el sistema anterior siga funcionando correctamente. En general, los números de revisión solo son de interés para el desarrollo interno y, de hecho, ni siquiera he visto que afecten a cosas que van mucho más allá de darle a las cosas un número adicional para realizar un seguimiento.

Sin embargo, los dos esquemas anteriores en realidad solo no se aplican a los entornos donde 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, como parece que se usa en los sitios de intercambio de pila. La razón de esto es que las versiones cambiarán con demasiada frecuencia en el entorno de implementación continua y es posible que haya varias versiones del código que se activen 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 las cosas. 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 de los hitos principales internamente que podrían facilitar el contacto entre las cosas.

    
respondido por el rjzii 19.01.2012 - 13:58
48

El problema con el uso de una fecha, es que las especificaciones se escriben en función de los números de conteo en lugar de una fecha a la que deben entregarse.

  

"Esta pieza de funcionalidad estará en la versión 1. La otra funcionalidad estará en la versión 2."

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

Si no tiene un proceso formal que requiera diferentes versiones identificadas de antemano, usar las fechas está bien; no es necesario 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. cuando la construcción tuvo lugar.

    
respondido por el StuperUser 27.01.2012 - 11:45
27

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

  • Las versiones basadas en fecha 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 se puede ver cuando fue escrito. Usted podría agrupar sus versiones basadas en fechas por mes, pero aún así no le diría nada. Podría tener varios meses lentos de corrección de errores pequeños y luego dos semanas de codificación pesada, lo que resultaría en un lanzamiento importante. Las fechas no te dicen eso, los números de las versiones regulares sí lo hacen.

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

respondido por el Goran Jovic 19.01.2012 - 13:20
12

Las versiones a menudo se usan para transmitir información acerca de qué tan 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 lleva 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 e 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

    
respondido por el JohnL 19.01.2012 - 13:09
10

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

Si haces una bifurcación, entre una versión anterior para compatibilidad con versiones anteriores y una nueva para una modernización incompatible, no puedes distinguirlos mediante 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 es compatible hoy en día y cuenta con 2.4.199, mientras que la nueva versión ha sido 2.6 por 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é pasa si hay una detección de errores en el último momento y un lanzamiento se retrasa durante una semana, pero la documentación, donde se menciona el nombre, ya está lista, tal vez impresa, la información de la prensa está fuera, etc. Ahora tiene una discrepancia que es problemática, si la versión 20120109 llegó a 2012/01/13.

En SQL, la pregunta sobre si los ID deben llevar información semántica se ha discutido a menudo, y el resultado siempre es: ¡evítalo como un demonio! 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 siguiente problema! :)

    
respondido por el user unknown 19.01.2012 - 21:13
6

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 productos de Microsoft Office también son una codificación de la fecha de construcción. Jeff Atwood escribió una publicación en el blog Coding Horror sobre numeración de versiones , incluyendo 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, positivamente debe usar los números de versión internamente, haga las fechas de todos modos: 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 siempre y cuando sea coherente y pueda pasar de un número de versión de compilación (sea lo que sea) y recordar todos los artefactos que entraron en esa compilación de su sistema de control de versiones. Por lo general, a los usuarios no les importa la información de la versión, sino la funcionalidad proporcionada por el sistema. La información sobre las versiones solo tiene un valor real para los desarrolladores.

    
respondido por el Thomas Owens 19.01.2012 - 21:47
4

Use el control de versiones semántico: de esa manera, tendrá una idea del tipo de cambios que se realizan entre las versiones sin tener que inspeccionar el código en sí mismo: enlace

    
respondido por el E.Z. Hart 19.01.2012 - 22:47
3

El uso de los 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 esta manera es fácil reconocer cuánto ha cambiado entre cada versión.

Habiendo dicho que 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 la versión de respaldo y la documentación de lo que estaba dentro del alcance de esa versión, no hay ningún problema real. .

    
respondido por el Daveo 19.01.2012 - 13:10
3

Algunas buenas respuestas ya están aquí, pero me gustaría señalar un caso en el que usar fechas tiene mucho sentido: pequeñas bibliotecas o fragmentos de código en los que es probable que el código se actualice con frecuencia, pero en pequeñas partes, sin una sola versión que difiera dramáticamente. al anterior.

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, por lo general me complace la opció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.

    
respondido por el UncleZeiv 19.01.2012 - 17:59
3

Las fechas como número de versión son buenas para la comercialización. Si la gente usa "Windows NT 5.0", es posible que no se den cuenta de que está obsoleto. Pero si la gente sigue usando "Windows 2000", sabrán al instante que es un sistema operativo de 12 años y se les alentará a que realicen la actualización.

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

    
respondido por el dan04 19.01.2012 - 18:16
2

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

Pero hagas lo que hagas: elige un esquema de denominación de versión y apégate a él . No lo hagas 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 de API (8), un número de versión destinado a marketing (2.2) y un nombre estúpido (Froyo).

    
respondido por el Mike Baranczak 19.01.2012 - 20:48
2

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 las fechas: el usuario no puede determinar con qué frecuencia se han realizado modificaciones.

Lo que estoy tratando de decir es que puedo decir que Windows 3.1 y Windows 7 están muy separados ... y quizás 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 miro más allá, veo que la versión 2.4.6 fue lanzada el 19 de diciembre de 2008; y esa versión 2.7.2 se lanzó el 11 de junio de 2011. A partir de esto, puedo formarme una opinión acerca de la estabilidad (es decir, la frecuencia de lanzamiento) de un producto.

Si, en cambio, Python utilizó fechas de lanzamiento, no puedo saber cómo se pueden conectar estos productos. Se generaría más confusión, ya que Python 3.1.4 también se lanzó el 11 de junio de 2011 (igual que Python 2.7.2).

En resumen, no creo que, por sí mismo, el control de versiones por fecha sea valioso.

    
respondido por el TheGeeko61 21.01.2012 - 02:49
1

Fecha como versión

Si su producto no se vende, solo 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, realmente no importa lo que sea, pero, por ejemplo, nadie compra realmente el 20 de enero de 2012, el Ford Car quiere el modelo Kia. Lo mismo ocurre con el software. Dar un nombre y versión de modelo duro significa que tiene características diferentes de las anteriores. Para mí, solo una fecha no hace eso, dice que lo hice entonces, no podría tener nuevas características.

Esquema que utilizamos

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

1200_GLD_120120_F0D1

Esto puede tener un límite superior, pero nos permite tener varias versiones de la compilación para la versión 1200 que nuestros ingenieros pueden usar y las diferenciamos entre ellas por fecha. El estado le dice a la gente si es una versión de prueba interna, una versión de parche del cliente o una versión de oro. La suma de comprobación es nueva, permite que un ingeniero o cliente verifique que realmente ha descargado el correcto 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 hacemos referencia a los principales números de versión para el cliente, es decir, "12", pero el cliente obtendrá la última versión de oro de 12, es decir, 1200_GLD_120120_F0D1, a menos que necesiten la Solución.

    
respondido por el David Allan Finch 20.01.2012 - 10:44
1

Digamos que algunos clientes usan la versión dos de su producto, y algunos se 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 arreglada, por lo que lanzará 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.

    
respondido por el gnasher729 23.07.2016 - 15:01
-1

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

Puede que no funcione en todos los casos.

    
respondido por el Scott Whitlock 19.01.2012 - 23:02
-2

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 que ¿cómo se siente? Si usa un número de fecha que pueda hacer que el software esté vivo, viva, como un hombre que cumple años. Cada año que estamos creciendo, lo mismo que el software es seguir creciendo.

El número del edificio se parece a la máquina, la máquina, no está vivo, no está vivo.

    
respondido por el Kanglando 23.07.2016 - 09:43

Lea otras preguntas en las etiquetas