Hace ya bastante tiempo hablamos “una buena manera de afrontar el branching en Git”, comentamos como crear ramas en nuestro proyecto para poder desarrollar nuevas funcionalidades de una manera más sencilla y efectiva. De la misma manera también hemos recomendado herramientas para utilizar git como “SourceTree”. Hoy vamos a hablar del versionamiento semantico, un mínimo conjunto de reglas que nos ayudan a aumentar números de versión a nuestro proyecto.
Esta es estrategia es bastante utilizada en las comunidades de software libre, como por ejemplo Ruby (a partir de 2.1.0), incluso parte de la comunidad PHP.
Versiones
Según está definido las versiones se numeran con la siguiente nomenclatura MAYOR.MENOR.PATCH
Ramas
Por lo general, la opción que quizás sea más aceptada es una rama por versión menor. Esto significa tener ramas como: 1.0, 1.1,1.2,2.0,… la “última” versión será la rama master.
Sin embargo, a veces lo de “ultima” puede sonar un poco ambiguo, ya que puede ser que tengamos versiones no definitivas, como 1.1-devque con el tiempo (y esfuerzo) será v1.1.0, o incluso ya podría haberse liberado la versión 1.1, por lo que la versión 1.1-dev sería la próxima versión v1.1.1.
Tags
Cada release se identifica con un tag. Un tag o etiqueta representa una versión del parche y conduce a realizar commits en la rama de esa versión menor. Por ejemplo el tagv1.0.0 indica que la rama de este desarrollo es la 1.0.
Esta manera de organizar las ramas, a diferencia de la versión de nvie ( 
)
en este caso no hay ramas dedicadas para las releases, ya que las versiones se pueden deducir de las etiquetas.
Bugfixes – Corrección de errores
En muchos casos habrá más de una rama activa al mismo tiempo. Los bugsfixes generalmente se realizan en la ultima rama compatible, es decir, cada vez que se corrige un error se realiza en la ultima versión disponible del proyecto. Por ejemplo, tenemos la versión 1.0de la que ya no se realiza mantenimiento, pero tenemos las versiónes 1.1y 1.2 activas. Si realizamos una corrección esta debe aplicarse a 1.1.
Aunque si bien es cierto, debemos tener en cuenta que 1.2es una rama posterior, por lo que también tendrá que tener todos las correcciones de errores. Por ello deberemos periódicamente fusionar 1.1y 1.2para que todo este bien.
Features – Caracteristicas
Según el versionado semántico, las nuevas funcionalidades/características deberían dar lugar a una nueva versión menor. Si la última release es v1.0.5, entonces debemos tener un master que representa la versión 1.1. Todas las nuevas funcionalidades deberían fusionarse en la rama master. Una vez que este liberado v.1.1.0, la rama 1.1debería dejar de la rama mastery la rama masterdebería pasar a ser `1.2’.
Quizás para proyectos pequeños esta regla podría no ser tan estricta y las nuevas features mezclarse en una rama que ya cuente con versiones. Pero debemos tener en mente que relajar esta regla puede legar a ser contraproducente, ya que perdemos la visibilidad de en que versión se introdujo una nueva característica.
Topic Branches
Normalmente el workflow para las contribuciones esta basado en topic branches. Se comienza con una nueva rama directamente desde la rama de versión, por ello utilizamos una rama separada para una nueva funcionalidad o bugfixes donde dicho cambio puede ser desarrollado de manera separada. Cuando este listo, lo que hacemos es mezclar la topic branch en la rama de versión. Quizás lo más explicativo en este momento sea un pequeño esquema:
Si el cambio abarca más de un commit, debemos ser cautelosos al realizar el merge, para poder revertir en caso de que sea necesario.
Lo más importante, es permitir nuevas funcionalidades puedan “proptotiparse”, es decir, que podamos crear nuevas funcionalidades sin necesidad de tener que integrar estos cambios en la versión, solo para pruebas.
topic branch son habitualmente ramas que tienen una vida muy corta y se cierran después del merge.
Conclusiones
Debemos tener en cuenta una serie de cosas, la primera de ellas es tener/identificar una API pública, esa será la que utilizaremos como base para los números de versiones.
Por el hecho de necesitar una API pública esta manera de versionar puede ser buena para proyectos Open Source o al menos proyectos que tengan expuesta funcionalidades a desarrolladores externos.
Básicamente todo esto puede resumirse en MAYOR.MENOR.PATCH
- PATCH: Aumenta solo cuando se corrigen errores que no modifican ninguno de los métodos públicos, es decir, no realizan cambios en el comportamiento.
- MENOR: Se incrementa cuando se añade una nueva funcionalidad compatible con la versión anterior, si algún método se marca como obsoleto debe aumentarse la versión menor.
- MAYOR: Se incrementa cuando se produce un cambio que es incompatible con alguna versión anterior, pueden incluir cambios menor y patch
Jesús L.C. - Apuntes de un aprendiz 
Muy buen post amigo 🙂
Me gustaMe gusta
Muy buen aporte, has explicado de forma concreta y concisa el uso de la especificación de versionamiento semántico para el control de versiones con GIT, tenía algún conocimiento muy vago sobre esto, gracias a este post tengo mucho más claro el concepto. Muchas gracias!
Me gustaMe gusta
la imagen de referencia que utilizaste en tu artículo tiene una rama dedicada para «releases» y tu comentario indica lo contrario: «en este caso no hay ramas dedicadas para las releases, ya que las versiones se pueden deducir de las etiquetas»
Me gustaMe gusta