¿Cómo versiona sus proyectos y administra las versiones?

Question

Nuestra situación es la siguiente, pero tengo curiosidad sobre este problema en cualquier situación.

tenemos un marco que consta de 4 proyectos:

• granos
• util
• marco
• web

También tenemos módulos que necesitan una versión y dependen de una versión de frijoles y util.

Finalmente tenemos un proyecto de cliente que consiste en una versión específica de los proyectos principales y uno o más módulos.

¿Existe una forma estándar de versión de estos proyectos?

Lo que a mí me parece simple es volverse realmente complicado cuando tratamos de entregar lanzamientos a QA y luego administrar nuestro desarrollo en curso con el mantenimiento del lanzamiento (release = tag y posible branch).

Yo como que prefieren los siguientes:

1.2.0 - mayores y menores versiones + liberación.

1.2.1 - próximo lanzamiento

1.2.0_01 - corrección de errores en la versión 1.2.0 (rama)

etc.

¿Alguna idea?

Answer 1

Utilizamos major.minor.bugfix. Una versión importante solo ocurre para grandes cambios. Se requiere una versión menor cuando hay un cambio de API. Todos los demás lanzamientos son versiones de corrección de errores. Definitivamente es útil tener un número de compilación o de revisión para la resolución de problemas, aunque si tienes un CM realmente riguroso, es posible que no necesites incluirlo.

La coordinación entre las versiones de todos estos proyectos se puede hacer muy bien con la ayuda de herramientas como Apache Ivy o Maven. La compilación de un proyecto, con su propio número de versión, puede implicar la agregación de versiones específicas de (los productos de) otros proyectos, por lo que sus archivos de compilación proporcionan un mapeo estricto de las versiones de abajo hacia arriba. Guárdelo todo en [inserte aquí la herramienta de control de versión favorita] y tendrá un buen historial grabado.

Answer 2

No hay sistemas de número de versión estándar. Los temas comunes son tener un número mayor, menor y de compilación, y ocasionalmente un número de punto también (1.2.2.1 por ejemplo, para la versión 1.2 punto versión 2 compilación 1). El significado de los números de versión es altamente flexible. Sin embargo, una opción frecuente es tener compatibilidad retroactiva entre versiones menores o versiones puntuales.

Las versiones probablemente se realicen mejor mediante el etiquetado de un conjunto de archivos controlados por fuente siempre que su control de fuente lo permita. Volver a crear una versión es tan simple como sincronizar con la etiqueta y la construcción, lo cual es muy útil :)

Answer 3

En el sistema de compilación automatizado actualmente estoy usando la versión I con Major.Minor.Build.X, donde Build es cada vez que tocamos la prueba del sistema, y ​​X es el último número de revisión de Subversion del repositorio desde el que se está creando el código. Parece que funciona bastante bien para Subversion, ya que podemos volver fácilmente a la base de código de una compilación en particular si surge la necesidad.

Answer 4

Siempre que sea posible, prefiero tener proyectos versionados con la misma numeración de compilación, a menos que sean compartidos. Permite una mayor coherencia entre las partes móviles y es más fácil identificar qué componentes constituyen una versión del producto.

Como ha declarado workmad3, en realidad no existe una regla común para los números de compilación. Mi consejo es usar algo que tenga sentido para su equipo/compañía.

Algunos lugares en los que he trabajado tienen alineación de numeración de compilación con hitos e iteraciones del proyecto,
e.g: Major = Release o Milestone, Minor = Iteration, Build = Build number (desde el inicio del proyecto o desde el inicio de la iteración), Revision = Si la construcción debe ser reconstruida (o ramificada).

Answer 5

Uso {major}. {Minor}. {Buildday}. {Sequential}. Para Windows, utilizamos las utilidades stampver.exe y UpdateVersion.exe para proyectos .NET que manejan eso de manera casi automática.

Answer 6

Usted no ha mencionado si alguno de los proyectos de acceso a una base de datos, pero si alguno lo hacen, que podría ser otro factor a considerar. Usamos un esquema major.minor.bugfix.buildnumber similar a otros descritos en las respuestas a esta pregunta, con aproximadamente la misma lógica, pero con el requisito adicional de que cualquier cambio en el esquema de la base de datos requiere al menos un incremento menor. Esto también proporciona un esquema de nombres para sus esquemas de base de datos. Por ejemplo, las versiones 1.2.3 y 1.2.4 pueden ejecutarse contra el esquema de base de datos "1.2", pero la versión 1.3.0 requiere el esquema de base de datos "1.3".

Answer 7

Actualmente no tenemos versiones reales. Usamos el número de compilación svn y la fecha de lanzamiento. (nombre de la etiqueta es como release_081010_microsoft por ejemplo)

Older Products utilizan versión major.minor.sub numeración

Major nunca cambió cambios menores en cada lanzamiento/featurerelease cada 6 meses. Sub es todo lo que no afecta al conjunto de características, principalmente correcciones de errores.

Answer 8

utilizo una variación en el Linux kernel del sistema de numeración de versiones:

major.minor.bugfix

donde incluso los números menores indican una liberación más o menos estable que puede ser distribuido al menos para la prueba, e impar menor los números indican una versión inestable/no probada que no debe distribuirse más allá de los desarrolladores.

Answer 9

una de las convenciones más comunes es major.minor.bugfix, con un sufijo adicional indicando una designación de número de compilación o pre-liberación (por ejemplo, alfa, beta, etc.).

Números equipo construye de acuerdo a los hitos del proyecto - una acumulación es entregado a nuestro grupo de control de calidad al final de una iteración de desarrollo (cada pocas semanas). Las construcciones CI intermedias no están numeradas; porque usamos Maven, esas construcciones están numeradas con un sufijo SNAPSHOT.

Decida lo que decida, asegúrese de documentar y asegurarse de que todo el mundo lo entiende. También sugiero que documente y aplique consistentemente la política de distribución de publicaciones o puede confundir rápidamente a todos. Aunque con solo 4 proyectos, debería ser bastante fácil hacer un seguimiento de lo que está sucediendo.