¿Qué significan realmente las versiones de actualización?

18

Muchas actualizaciones de software siguen el esquema de v0.1 a v0.2 a v2.6.5.6 . ¿Qué significan realmente estas "actualizaciones" de software? ¿Se sigue siempre un estándar de la industria o los programadores siguen aumentando la actualización # o agregando más decimales?

deployment software-updates software-distribution

— James Mertz
fuente

12

@ S.Lott Como soy bastante nuevo en la escena de la programación, no sabría especificidades. Esta es la mejor manera de pedir que se me ocurra.

— James Mertz

99

@ S.Lott, reduzca el consumo de cafeína señor, lo está poniendo irritable.

— ocodo

2

@ S.Lott no dude en editar como mejor le parezca para mejorar la pregunta. Siento que sabes lo que estoy buscando. Sin embargo, creo que las respuestas proporcionadas han sido muy buenas. También siento, a juzgar por los votos positivos en mi comentario anterior, que he hecho lo mejor que he podido y que la pregunta está bien como está. Sin embargo, agradezco las críticas, así como las ediciones. Haz lo que mejor te parezca. Para mí, lo estoy dejando solo.

— James Mertz

1

@ S.Lott La pregunta parece bastante clara como lo es para mí. No creo que enumerar una organización específica de redacción de normas sea una mejora considerable. Si sientes lo contrario, no dudes en editar. Tienes el representante para ello.

— Adam Lear

3

@ S.Lott: "¿Hay un estándar de la industria" está completamente bien. Sí, hay estándares de la industria! No importa quién los escriba: KronoS quiere saber qué significan las versiones, es su elección especificar qué tan detallado va ... ¿Quizás debiste haber mencionado que consideras que la pregunta es amplia? Simplemente insistir en los detalles no deja eso claro para el usuario, diciéndole a un usuario que defina: la palabra no deja eso claro para el usuario, diciendo que no tiene sentido después de que su primer comentario no lo deje claro para el usuario.

— Tamara Wijsman

16

Como dijo Shaun, en realidad no hay un estándar. Algunas compañías tienen mejores prácticas de versiones que otras (he tratado con proveedores que se saltan los números de versiones principales, y otras que están atrapadas en el mismo xy varias versiones más adelante).

Dicho esto, el inventor de Gravatars y cofundador de GitHub ( Tom Preston-Werner ) escribió un documento para ' Versiones semánticas ' que vale la pena leer.

Aquí está la excepción de la introducción:

Como solución a este problema, propongo un conjunto simple de reglas y requisitos que dictan cómo se asignan e incrementan los números de versión. Para que este sistema funcione, primero debe declarar una API pública. Esto puede consistir en documentación o ser aplicado por el propio código. En cualquier caso, es importante que esta API sea clara y precisa. Una vez que identifica su API pública, le comunica los cambios con incrementos específicos a su número de versión. Considere un formato de versión de XYZ (Major.Minor.Patch). Las correcciones de errores que no afectan la API incrementan la versión del parche, las adiciones / cambios de API compatibles con versiones anteriores incrementan la versión menor, y los cambios de API incompatibles con versiones anteriores aumentan la versión principal.

Yo llamo a este sistema "Versiones Semánticas". Bajo este esquema, los números de versión y la forma en que cambian transmiten significado sobre el código subyacente y lo que se ha modificado de una versión a la siguiente.

— Dan McGrath
fuente

7

Con 4 dígitos, generalmente es MajorV.MinorV.PatchNum.BuildNum, al menos donde trabajo.

Personalmente prefiero el esquema de versiones de Ubuntu, hace la vida mucho más fácil.

— Trabajo
fuente

¿Cuál es su esquema? ¿Por qué los prefieres?

— James Mertz

3

Ubuntu 10.10 = octubre de 2010, Ubuntu 10.04 = abril de 2010, Ubuntu 11.04 = abril de 2011, Ubuntu 9.10 = octubre de 2009, etc. Esto se menciona en el enlace de Wikipedia de Shaun.

— Trabajo

2

Lo bueno de usar fechas como números de versión es que, a menos que ocurra una paradoja extraña, su número de versión siempre estará en el orden correcto. Para la mayoría de nosotros, es más fácil recordar que hoy es 2011.02.13 que tratar de descubrir qué versión de la nueva versión debería ser.

— jmort253

@ jmort245, ¡Exactamente! Los sistemas hechos por el hombre son bastante desordenados. Los malditos bancos piensan que hay 360, 362, 365, 366, etc. días en un año. El sistema de versiones es otra de esas estúpidas creaciones. Las marcas de tiempo no nos hacen pensar, aunque 20050207 tarda un poco más en leer y resolver que 502. ¿Qué software se lanza más de una vez al mes?

— Trabajo

2

@job: pero el uso de versiones le permite vincular características con versiones principales o menores específicas. Entonces, si tengo la versión 2, sé que tengo la función X, mientras que la versión 1 no tiene la versión X.

— Martin York

6

La versión corta es que no hay un estándar y las empresas hacen lo que quieran. Esencialmente, cuantos más números tenga, menor será la cantidad de cambios que representa cada número. Comúnmente, verá al menos la versión xy, donde el cambio de xa en x significa lanzamientos importantes (mejoras importantes / despliegues de funciones) e y significa lanzamientos menores (ajustes significativos o correcciones de defectos). Más decimales después de esos dos pueden significar cosas diferentes internamente para una empresa, aunque a menudo giran en torno a compilaciones de contenido menores o parches que representan soluciones más rápidas y pequeñas.

Wikipedia tiene un artículo que cubre esto con mayor detalle.

— Shaun
fuente

3

El propósito de los números de versión es proporcionar una referencia para los informes de problemas. El único requisito es que cada versión tenga un número de versión único. Algunos números son impulsados por el marketing: los números enteros más grandes son más fáciles de vender, y los números de potencia como el 10 (número romano X) son realmente pegadizos. Algunas personas usan alguna variación de las versiones semánticas:

MAYOR.MINOR.MICRO.BUILD

Incrementos importantes: cambios incompatibles o rediseño completo de la IU
Incrementos menores: nuevas funciones agregadas, compatibles con versiones anteriores en el mismo número de versión principal
Micro incrementos: lanzamiento de corrección de errores
Número de compilación: generado por el compilador o extraído del control de versiones

Muchos grupos eliminan el número de BUILD en sus lanzamientos. Por lo general, solo es útil entre los grupos de prueba y desarrollo.

Algunos grupos agregan semánticas adicionales, como los incrementos MENORES con números impares son para compilaciones experimentales e incrementos MENORES con números pares son para lanzamientos de producción (el kernel de Linux usa este enfoque).

La conclusión es que no hay un estándar, aparte de que las versiones más nuevas usan números de versión más altos, y que cada número de versión es único.

— Berin Loritsch
fuente