version - que - ¿Cómo sabes qué número de versión usar?

etiqueta head para que sirve (12)

Aquí hay uno sobre el que siempre me he preguntado ...

Disculpe mi ingenuidad, pero - ¿Cómo decide qué número de versión nombrar su software?

Supongo que, cuando alguien crea una versión "final" de una aplicación / programa, ¿es la versión 1.0? - Entonces, ¿qué sucede cuando lo actualizas, cómo decides llamarlo 1.1 o 1.03 etc. etc.

¿Esto es principalmente para el desarrollador?

Jeff Atwood tiene una publicación en el blog sobre esto, en la que defiende el uso de las fechas y no confunde al usuario con los números de versión. Sin embargo, él discute el enfoque que Microsoft ha tomado: Usar las fechas para determinar los números de versión. Él entra bastante profundidad en su publicación, así que no voy a duplicar su trabajo aquí. En cuanto al control de versiones:

Versiones (al menos en .NET, ve algo como esto):

1.2.3.4 donde:

1 es el lanzamiento principal
2 es la versión menor
3 es el número de compilación
4 es el número de revisión

Versión principal : significa un sistema "completo" con las funciones que la versión debía tener. Normalmente, cualquier versión "importante" posterior es reescritura, o cambios de arquitectura, o (excusa la redundancia), cambios importantes en el software.

Versión menor : significa una versión menos significativa, con correcciones de errores, pequeñas características añadidas o cualquier cantidad de eventos "menores". Esto podría incluir cambios de interfaz y adiciones. Normalmente, las aplicaciones deberían ser algo compatibles en su árbol de "lanzamiento principal", por lo que las versiones menores de la misma versión principal deberían ser arquitectónicamente iguales.

Número de compilación : en general, solo significa correcciones de errores, pequeñas correcciones y son algo insignificantes en su alcance. Podría ser algo tan simple como cambiar el contraste entre el primer plano y el fondo de la aplicación. En general, las compilaciones son designaciones internas, como construcciones nocturnas, por lo que siempre tienes un lugar al que volver para que sea estable.

Número de revisión : significa cuando se liberan las correcciones de errores o se realizan mejoras MÍNIMAS. En general, se reservan solo para correcciones de errores: no incluya mejoras importantes de funciones como revisiones .

Recientemente escuché una estrategia de control de versiones más pizca, que encontré por primera vez en la cuenta Mediana de Eric Elliot . Es más importante para las versiones de la biblioteca que los números de versión de los clientes, pero tiene la ventaja de la simplicidad. Use un número de versión de tres partes, donde cada número significa:

breaking.feature.fix

rompiendo : algo ha cambiado, eso significa que el código / las expectativas deben cambiar
característica : se agrega algo nuevo, pero el código / expectativas anterior funcionará bien.
solución : no hay nada nuevo, pero se ha corregido un error.

Dejo mi respuesta anterior a continuación, ya que sigue siendo relevante para las versiones orientadas al cliente.

Tiendo a pesar los dígitos significativos de la siguiente manera ...

wxyz (o w.xyz)

w - Versión principal, con muchas características nuevas. Una actualización pagada. El primer lanzamiento público de software es 1.X (las versiones preliminares son 0.X)
x - Lanzamiento significativo, pero sin nuevas características innovadoras.
y - Lanzamientos de Bugfix
z - Versiones de nivel de parche (solucionando un error de emergencia, quizás solo para un cliente).

Si elige usar el formato w.xyz, solo obtendrá 9 dígitos antes del desbordamiento. Sin embargo, si liberas eso a menudo, es posible que tengas un problema mayor.

¡Vamos a ilustrar con FooApp, mi nuevo producto!

0.9 - La primera versión beta pública
0.91 - La segunda versión beta pública
0.911 - La versión beta de emergencia para corregir un bloqueo en el Motorola 68010
1.0 - La primera publicación pública
1.1 - Se agregó la nueva función BlahBaz
1.11 - Corrección de errores
2.0 - Interfaz totalmente renovada.

A B C D

A: 0 cuando es beta, 1 cuando se lanza por primera vez, más grande que 1 en reescritura casi completa.
B: nuevas funciones añadidas
C: correcciones de errores hechas
El número de revisión del depósito de control de versiones

Asignamos a cada versión de cualquier aplicación un número de versión de cuatro partes definido como Major.Minor.Maintenance.Build .

Mayor : el número principal está asociado a cambios significativos en la aplicación. Este número también determina la compatibilidad con otras aplicaciones en el mismo "paquete". Este número se incrementa cuando se hacen nuevas versiones. Esto generalmente significa que se han producido importantes cambios arquitectónicos.

Menor : el número menor está asociado a una nueva funcionalidad y corrección de errores. Cada vez que se introduce una nueva funcionalidad o cuando se aplica una solución de corrección de fallas, este número se avanzará y el número de Mantenimiento se establecerá en cero.

Mantenimiento : el número de Mantenimiento está asociado con correcciones de errores sin interrupción. Este número se avanzará cada vez que se realice una publicación que contenga correcciones de errores que no sean interrupciones.

Generar : el número de compilación está asociado al conjunto de cambios de subversión (número de revisión) desde el cual se compiló la aplicación. Esto proporcionará una manera fácil de hacer coincidir el número de versión con un conjunto preciso de código en subversión.

El único número que los desarrolladores realmente están interesados en este esquema es Build . número. Al vincular el número de compilación al número de revisión de subversión, podemos garantizar qué código se utilizó para crear la aplicación liberada.

Creo que el kernel de Linux es una buena referencia para esto:

El número de versión del kernel de Linux actualmente consta de cuatro números, después de un cambio reciente en la política de larga data de un esquema de versiones de tres números. Para ilustración, supongamos que el número de versión está compuesto así: ABC [.D] (ej. 2.2.1, 2.4.13 o 2.6.12.3).
* The A number denotes the kernel version. It is rarely changed, and
solo cuando ocurren cambios importantes en el código y el concepto del kernel. Se ha cambiado dos veces en la historia del kernel: en 1994 (versión 1.0) y en 1996 (versión 2.0).
* The B number denotes the major revision of the kernel. o Prior to the Linux 2.6.x series, even numbers indicate a stable
liberación, es decir, una que se considera apta para el uso de producción, como 1.2, 2.4 o 2.6. Los números impares han sido históricamente versiones de desarrollo, como 1.1 o 2.5. Fueron para probar nuevas características y controladores hasta que se volvieron lo suficientemente estables como para ser incluidos en una versión estable. Era un esquema de número de versión par / impar. o Comenzando con la serie Linux 2.6.x, no hay importancia para los números pares o impares, con el desarrollo de nuevas características en la misma serie kernel. Linus Torvalds ha declarado que este será el modelo para el futuro previsible.
* The C number indicates the minor revision of the kernel. In the old
Esquema de versiones de tres números, esto se modificó cuando se implementaron parches de seguridad, corrección de errores, nuevas características o controladores en el kernel. Con la nueva política, sin embargo, solo se cambia cuando se introducen nuevos controladores o características; las correcciones menores son manejadas por el número D.
* A D number first occurred when a grave error, which required immediate
fijación, se encontró en el código NFS de 2.6.8. Sin embargo, no hubo otros cambios suficientes para legitimar el lanzamiento de una nueva revisión menor (que hubiera sido 2.6.9). Entonces, se lanzó 2.6.8.1, siendo el único cambio la solución de ese error. Con 2.6.11, esto fue adoptado como la nueva política oficial de control de versiones. El cuarto número administra las correcciones de errores y los parches de seguridad, mientras que los cambios más grandes solo se implementan en cambios de revisión menores (el número C). El número D también está asociado con la cantidad de veces que el compilador ha construido el núcleo, y por lo tanto se llama el "número de compilación".
Además, algunas veces después de la versión habrá más letras como ''rc1'' o ''mm2''. El ''rc'' se refiere al lanzamiento del candidato e indica un lanzamiento no oficial. Otras letras suelen ser (pero no siempre) las iniciales de una persona. Esto indica una rama de desarrollo del núcleo por esa persona. por ejemplo, ck significa Con Kolivas, ac significa Alan Cox, mientras que mm significa Andrew Morton. A veces, las letras están relacionadas con el área de desarrollo principal de la rama desde la que está construido el kernel, por ejemplo, wl indica una construcción de prueba de red inalámbrica.

De http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Esto es lo que uso para módulos en proyectos de C incrustados:

1.00 - Lanzamiento inicial

1.01 - Revisión menor
No hay cambios de interfaz en el módulo (es decir, el archivo de cabecera no ha cambiado). Cualquiera que use mi módulo puede actualizar sin tener que temer romper el código. Podría haber hecho alguna refactorización o limpieza de código.

2.00 - Revisión principal
La interfaz del módulo ha cambiado (es decir, las funciones añadidas, eliminadas o la funcionalidad de ciertas funciones ha cambiado). Una actualización a esta revisión muy probablemente romperá el código existente y requerirá la refactorización del código usando este módulo.

Debo agregar que esto se refiere a la etapa de desarrollo, es decir, las versiones internas de los módulos en el proyecto.

Independientemente del esquema de numeración que escoja, es fundamental dejar en claro a sus usuarios cuando una nueva versión es compatible con un código de cliente anterior, en comparación con una nueva versión que requiere cambios en los clientes existentes . La mayoría de los proyectos que conozco superan el primer número cuando el código del cliente tiene que cambiar.

Más allá de la compatibilidad, también creo que hay mucho que decir sobre el uso de las fechas. Aunque resulta embarazoso si, como yo, su calendario de lanzamiento es una vez cada dos años (pero eso es para una herramienta lanzada por primera vez en 1989).

Lo más probable es que alguien en ventas o marketing decida que necesitan algo de entusiasmo. Esto determinará si la próxima versión es 1.01 o 1.1 o 2.0. El tipo de trabajo es el mismo en código abierto, pero tiende a estar vinculado a una característica nueva y elegante de la que el equipo está orgulloso.

Para agregar a toda la explicación anterior, sugeriré utilizar un esquema de control de versiones que será fácil de recordar para sus clientes y fácil para usted baseline y administrar sus versiones de software. Además, si está soportando un marco diferente como .Net 1.0, .Net1.1, etc., entonces asegúrese de que su esquema de control de versiones también se encargue de eso.

En el caso de una biblioteca, el número de versión le informa sobre el nivel de compatibilidad entre dos versiones y, por lo tanto, qué tan difícil será una actualización.

Una versión de corrección de errores necesita preservar la compatibilidad binaria, fuente y serialización.

Los lanzamientos menores significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de la fuente.

Los números de versión principales pueden romper las tres formas.

Escribí más sobre la razón de ser aquí .

Depende del proyecto. debajo está la política de control de versiones del paquete de Haskell.

-- The package version. See the Haskell package versioning policy (PVP) -- for standards guiding when and how versions should be incremented. -- http://www.haskell.org/haskellwiki/Package_versioning_policy -- PVP summary: +-+------- breaking API changes -- | | +----- non-breaking API additions -- | | | +--- code changes with no API change version: 0.1.0.0

una buena información aquí también ...

Cuándo cambiar las versiones de archivo / ensamblaje

Cuándo cambiar las versiones de archivo / ensamblaje En primer lugar, las versiones de archivo y las versiones de ensamblaje no necesitan coincidir entre sí. Recomiendo que las versiones de los archivos cambien con cada compilación. Pero no cambie las versiones de ensamblaje con cada compilación solo para que pueda distinguir entre dos versiones del mismo archivo; usa la versión del archivo para eso. Decidir cuándo cambiar las versiones de ensamblaje requiere una discusión sobre los tipos de construcciones que se deben considerar: envío y no envío.

Desarrollos no relacionados con el envío En general, recomiendo que las versiones de ensamblado que no son de envío sean iguales entre las compilaciones de envío. Esto evita problemas de carga de ensamblaje fuertemente nombrados debido a discrepancias de versión. Algunas personas prefieren usar la política del editor para redirigir nuevas versiones de ensamblaje para cada compilación. Sin embargo, recomiendo esto para las versiones que no sean de envío: no evita todos los problemas de carga. Por ejemplo, si un socio copia x su aplicación, es posible que no sepa instalar la política del editor. Entonces, su aplicación se romperá para ellos, a pesar de que funciona bien en su máquina.

Pero, si hay casos en que las diferentes aplicaciones en la misma máquina necesitan vincularse a diferentes versiones de su ensamblaje, recomiendo darles a esas construcciones diferentes versiones de ensamblaje para que se pueda usar la correcta para cada aplicación sin tener que usar LoadFrom / etc.

Creación de envíos En cuanto a si es una buena idea cambiar esa versión para el envío de compilaciones, depende de cómo quiera que funcione el enlace para los usuarios finales. ¿Desea que estas construcciones estén una al lado de la otra o en el lugar? ¿Hay muchos cambios entre las dos versiones? ¿Van a romper algunos clientes? ¿Te importa que los rompa (o quieres obligar a los usuarios a usar tus actualizaciones importantes)? En caso afirmativo, debería considerar incrementar la versión de ensamblaje. Pero, nuevamente, considere que hacerlo demasiadas veces puede ensuciar el disco del usuario con ensamblajes desactualizados.

Cuando cambia las versiones de su ensamblaje Para cambiar las versiones codificadas a la nueva, recomiendo configurar una variable para la versión en un archivo de encabezado y reemplazar la codificación rígida en las fuentes con la variable. Luego, ejecute un pre-procesador durante la compilación para poner la versión correcta. Recomiendo cambiar las versiones inmediatamente después del envío, no antes, para que haya más tiempo para detectar errores debido al cambio.