Este pequeño post tiene un vínculo demasiado estrecho con esa obsesión casi compulsiva de revisar qué cosas hago y por qué las hago (y si tiene sentido hacerlas). La preguntonta del día de hoy es: ¿cómo versionar y taguear un proyecto?
Desde hace algo más de una década mi trabajo principal ha sido sobre tiendas Magento, y no tanto sobre producto(s). Esta diferencia, en mi estructura de razonamiento, me permite marcar una separación (aunque también podría juntar argumentos para oponerme).
La línea de diferenciación la trazo entonces entre el versionado de un proyecto al versionado de un componente del mismo. Es decir, la diferencia entre el versionado de una tienda, de este blog o de un proyecto que está (como ya dije alguna vez) vivo; de las librerías o módulos que componen esa tienda, blog, etc.
En el pasado siempre adherí sin dudar al versionado semántico, pero en algún punto me empezó a generar ruido, en particular cuando hablaba con un cliente/merchant/product owner, el referirme a la versión 1.14.1 para indicar el estado del proyecto, o a la versión deployada en producción.
Entiendo que esa referencia es no sólo arbitraria sino que es insignificante como referencia para todo aquel que no está del lado del código.
Por el contrario, hablar de la versión 2021.12.29 (por seguir el formato YYYY.MM.DD) me permite ubicarme temporalmente. Probablemente sea más fácil recordar el problema que tuvimos en la versión 2020.03.15 que con la versión 2.102.3, ya que nos estaríamos ubicando (en este ejemplo inventado) en lo sucedido en marzo de 2020, y podríamos relacionarlo fácilmente con el comienzo definitivo de la pandemia. O tener otras fechas que se relacionen con otros eventos y nos ubiquen de forma rápida.
¿Cómo funciona esto con los diferentes workflows de trabajo con repositorios? No creo que presente un problema incluso si se utilizan release branches (cosa con lo que dependiendo el tamaño del proyecto y del equipo, muchas veces tengo cierto nivel de rechazo), ya que a pesar de los release branches siempre debería existir el tag (por su inmutabilidad) (a diferencia de los branches que deberían eliminarse una vez mergeados).
Leyendo un poco (no tan poco) sobre versionado y gestión de proyectos, pude ver que preguntarme si era sólo que a mi se me salía la cadena fue una pregunta válida (y la respuesta fue que estaba lejos de ser una pregunta original).
La respuesta a esa pregunta es CalVer, que básicamente ofrece un cuadro mínimo (no hay tanto en cuanto al esquema) de cómo usar el versionado por calendario en lugar de números que podrían resultar arbitrarios para los proyectos.