¿Cómo se colocan diferentes versiones de su biblioteca bajo control de versiones? ¿Usas etiquetas? O ramas? ¿U otro método?

Recientemente comencé a poner mi código bajo control de versiones (en el laboratorio en el que estoy trabajando, bajo SVN, y mis propios códigos en github (obviamente con git)). Antes de usar el control de versiones, solía hacer algo como esto. Tenía una carpeta con el nombre de la biblioteca, dentro de muchas carpetas con el número de versión. Cada vez que quería comenzar a trabajar en una versión más nueva, hacía una copia de la última versión, cambiaba el nombre a la nueva versión y comenzaba a implementarla.

Sin embargo, esto parece redundante cuando la carpeta se pone bajo control de versión. Además de la redundancia, si alguien quiere obtener la última versión, descargaría todas las versiones si solo fuera imports / clones.

Ahora veo muchas formas de hacerlo con el control de versiones, pero como soy nuevo en esto, no sé cuál sería más fácil de mantener.

Método 1: uso de etiquetas

Si entendiera correctamente las etiquetas, tendría su rama principal, confirmará cualquier cambio que tenga y las etiquetará con una versión. Luego, cuando desea obtener una copia de trabajo de la misma, obtiene la que tiene una determinada etiqueta. (corrígeme si me equivoco)

Método 2: versiones de ramificación

En este método, la rama principal sería la rama de desarrollo. De vez en cuando se hace una versión estable (digamos v1.2.0), se crea una rama para esa versión y nunca se compromete. De esa manera, si desea descargar una determinada versión, obtendrá el código de esa rama. Aunque dije que nunca se compromete a ello, es posible hacer correcciones de errores y comprometerse con la rama de una versión anterior para mantener la versión anterior en ejecución. Por ejemplo, si la versión actual es v2.0, pero hay personas que quieren usar v1.2, puede obtener otra rama v1.2, a saber, v1.2.1y confirmar las correcciones de errores, o simplemente mantener la versión igual v1.2y simplemente confirmar las correcciones de errores.

Entonces las ramas se verían así:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

De esta forma, tiene sucursales para cada actualización de versión menor. (Tenga en cuenta que en el gráfico anterior, v1.2.1 y v1.2.2 o creado después de que se lanzó v2.0.0, por lo que no formaron parte del desarrollo entre v1.2.0 y v2.0.0. Piense en ello como soporte para versiones anteriores)

Método 3: desarrollo de ramificaciones

Este método es lo opuesto al anterior. La rama principal sería la última versión estable. Siempre que esté trabajando en una nueva versión, cree una rama (para el desarrollo), trabaje en su código y cuando sea estable, combínelo con la rama principal.

En este caso, las ramas se verían así:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Probablemente este debe hacerse junto con las etiquetas ¿verdad?

¡La pregunta!

De todos modos, mi pregunta es que, según su experiencia, ¿cuál de estos métodos resulta más práctico? ¿Existe un mejor método conocido por ahí (que posiblemente no descubrí yo mismo)? ¿Cómo se hacen comúnmente estas cosas?

Las etiquetas y las ramas no son mutuas, puede (y la OMI generalmente debería) usar ambas. Las etiquetas están ahí para marcar hitos en el desarrollo. Por ejemplo, se abra una rama de la versión 1.2 de su producto, y se marca v1.2 Beta, RC1, RC2, Final(y luego, si es necesario, SP1etc.) con las etiquetas en la misma rama.

Personalmente prefiero el Método 2 como el enfoque predeterminado (aunque trato de evitar múltiples niveles de ramas, para mantener la vida lo más simple posible). El método 1 simplemente no va a funcionar en la vida real: las etiquetas no son suficientes, necesitas ramas. Y el método 3 es inflexible porque solo tiene una versión estable en todo momento, por lo que (a menos que lo combine con el Método 2), no puede mantener varias versiones (más recientes y más antiguas) en paralelo. Esto es necesario para casi todos los proyectos en la vida real: mientras trabaja en la versión 2, aún debería poder publicar parches / actualizaciones para v1.9, y a menudo incluso versiones anteriores. Mucho depende del tipo de aplicación, por supuesto. Desarrollamos una aplicación web, por lo que solo hay una versión de producción en un momento dado, pero a menudo hacemos malabares con 3 versiones diferentes (una en producción, uno está en UAT preparándose para la implementación, uno es la última versión en el tronco). Puede ser mucho más complejo para una aplicación de escritorio / cliente con múltiples versiones antiguas que se usan, y se mantienen, en paralelo.

Tenía una carpeta con el nombre de la biblioteca, dentro de muchas carpetas con el número de versión.

Esto es efectivamente, como notará, un enfoque incorrecto, ya que ya tiene el control de versión para ... controlar las versiones.

Ahora, las diferentes técnicas que enumeras parecen igualmente correctas. Puede leer un artículo muy detallado, Source Control Done Right , que incluye información sobre etiquetas y ramas.

Los tres métodos no son mutuamente excluyentes, y debe combinar los tres para aprovechar al máximo su control de versiones.

Por mi parte, utilizaría una combinación de los métodos 1 y 3 de forma predeterminada, es decir, desarrollar en una característica o rama de desarrollo hasta que una característica esté lista para la producción y luego volver a fusionarse en el tronco. De esta forma, el enlace troncal siempre representa el estado actual del desarrollo estable que se utilizará y puede vincularse de manera segura mediante svn: proyectos externos. Cuando lance una versión, etiquétela.

Sólo había rama de la demanda, es decir, cuando las versiones anteriores de la biblioteca tienen un error que tiene que ser fijo. Puede crear fácilmente esa rama desde la etiqueta de la versión rota. Al no ramificarse innecesariamente, mantiene baja la cantidad de ramas y tiene una visión general rápida de los bordes sangrantes que deben mantenerse (tronco y todas las ramas).

Yo usaría el Método 2 . Utilicé esto y descubrí que es una forma efectiva de administrar y mantener múltiples versiones al tiempo que permite que el desarrollo actual avance. También puede usar etiquetas junto con este método si las necesita.

Vea mi respuesta aquí para obtener más información sobre el uso de la ramificación para mantener varias versiones de lanzamiento.