Qué esquema de número de versión para la aplicación mal planificada, ramificada y esquizofrénica

Question

Estoy buscando un esquema/esquema/sistema de numeración de versión para una aplicación que actualmente está ramificada en varias versiones con fechas de lanzamiento de estilo shell game. Esto ha convertido las versiones en una pesadilla. Me gustaría simplemente usar el típico Major.Minor.Revision; sin embargo, esto se descompondrá rápidamente para mí de la misma forma en que se están ejecutando las cosas aquí.

Aquí está mi inventario ...

• 1.0.0 - Versión de producción.
• 1.0.1 - Producción revisión versión con la corrección de errores.
• 1.1.0 - Producción menor versión con nuevas características vencidas en julio (cumplimiento de las normas, debe hacerse).
• 1.2.0 - Producción versión menor con nuevas características para integrarse con todavía-no-lanzado-todavía-subdesarrollo Sistema A.
• 2.0.0 - Desarrollo principal versión "2.0" del producto (código migrado a una plataforma más nueva, usabilidad mejorada).

Y para hacerlo más divertido, están planeando otro proyecto (nuevas características) para la integración con un sistema diferente.

• 1.3.0 - Producción versión menor con nuevas características de integración con el Sistema B .

Agregando a la complejidad es el hecho de que no sabemos exactamente cuándo (leer: el orden en que) van a "entrar en vigencia". Si uno de los sistemas con los que estamos integrando se retrasa, la administración cambia el calendario de lanzamientos. Así que la versión 1.2.0 de hoy podría retrasarse y la compilación que etiquetamos como 1.3.0 caería primero. La coordinación con QA ya es bastante difícil sin cambiar las etiquetas de versión al final del ciclo.

Preguntas? ¿Pensamientos? Pequeños animales peludos?

la paz | dewde

Answer 1

Me parece que no desea utilizar los números de versión específicamente. Puede usar nombres en clave, (Windows hizo esto con cada uno de sus lanzamientos antes de ser lanzados). Básicamente necesita algo más que números para distinguir en la casa de qué rama está hablando. A medida que se lanzan las versiones, puedes darle una bofetada a Major.Minor.Sello de revisión en ellos, pero hasta entonces debe nombrarlos de una manera que sea reconocible.

Dividirlos en ramas y ramas secundarias. Asegúrese de que todo lo que dependa de una rama superior tenga un nombre derivado. Por lo tanto, podría llamar a una sucursal ProductionMac y una sucursal ProductionWindows, y de ese modo sabría al instante que no se fusionarán, y que ambas derivan de la producción.

Lo más importante para mantener es la jerarquía estructural. Los números de versión hacen esto bastante bien, pero debe seguir agregando "." para cada nueva capa, que es molesto y completamente no descriptivo (como nombrar sus variables variableOne, variableTwo, variableThree) Por lo tanto, asegúrese de que, independientemente de cómo elija etiquetar cada rama, todavía es obvio qué ramas están relacionadas con qué otras ramas.

Answer 2

Suena como los números no van a ayudar mucho, me gustaría ir con el nombramiento de los lanzamientos después de pequeños animales peludos.

O, nombre cada versión después del proyecto que generó ('UI overhaul', 'June maintenance', etc.), y luego solo asigne un número de versión cuando entre en funcionamiento?

Answer 3

Usaría un diccionario para mapear números de desarrollo interno y números de "liberación" externos, luego usaré internamente los números de desarrollo interno y solo expondré los números de "liberación" cuando esté listo para liberarlo del desarrollo.

Puntos de bonificación si utiliza un mapa intermedio con números irracionales. "¿Cómo va el desarrollo en la versión 3.14159?" "Oh, no está mal, pero todavía estoy reparando un error que encontramos en el lanzamiento 2.71828183". "¿Qué? ¿Ese error? ¡Se suponía que se solucionaría con la versión menor 1.73205!" :-)

Answer 4

Según lo que describes, estoy de acuerdo con las primeras dos publicaciones. Los nombres significativos y únicos relevantes para el alcance/conjunto de características son probablemente el camino a seguir para cada rama. Las versiones numeradas parecen razonables dentro de cada rama nombrada.

Lo que realmente necesita ... es el etiquetado de estilo Gmail ... para su versión!

Answer 5

Como han sugerido otros, utilice un nombre de código no numérico internamente, y aplique un número a medida que se libera cada componente.

Agregar un número de revisión/compilación a su versión puede ayudarlo a asociar este nombre clave interno con el número de versión externa (y puede ayudar en la comunicación con QA).

Por ejemplo:
RegulationCompliance r1234 corresponde a la versión 1.1.0.1234.

Answer 6

en las publicaciones anteriores.

Nuestro sistema de compilación incrementa el número de compilación después de cada compilación (tanto si se lanzará como si no), que es lo que dev/QA usa para identificar compilaciones. La versión final # está SOLAMENTE expuesta al mundo exterior cuando se lanza QA. Entonces, realmente hay compilaciones múltiples de 1.3.0.x, pero solo una verdadera 1.3.0.

Answer 7

Aquí hay otra alternativa que consideré mientras desarrollaba esto ayer. Tal vez deba volver a pensar lo que se considera mayor. La integración con otro sistema puede ser una pequeña cantidad de trabajo, pero si afecta la programación y las fechas de lanzamiento y la versión de una manera tan significativa, como lo hace para mí aquí, tal vez solo sea un impacto lo suficientemente grande como para llevar la rama hasta principal estado. Entonces algunos de mis dolores de cabeza se reducirían al mínimo.

Los escenarios más probables para liberar versiones desordenadas giran en torno a iteraciones menores. Los principales toman un esfuerzo coordinado entre departamentos. Puedes verlos en el horizonte.Los menores se le acercan sigilosamente y levanten todo.

"Aquí están los nuevos reglamentos cumplimiento . Si no van en vivo por 15 de julio vamos a ser multados $ 500.000. por día."

"¿Qué? ¿Cuándo obtuviste estos?"

"El pasado mes de julio. ¿No estuvo CC'd en la distribución ?"

** ** facepalm

sigo pensando que la respuesta de Devinb es mejor. Pero quería arrojar esto aquí para otros en este dilema.

la paz | dewde