Semantic versioning no es decoración: la disciplina de un solo desarrollador
RAXXO, un estudio unipersonal, explica por qué sigue semver estricto y cómo evitar que un parche rompa compatibilidad.
Cada herramienta de RAXXO se publica bajo versionado semántico estricto, major.minor.patch, y su creador asegura que nunca rompe ese patrón, ni para un arreglo pequeño. Un bump de parche significa que solo se corrigió un bug; uno menor agrega funcionalidad sin romper nada anterior; uno mayor es una promesa que solo se hace con aviso. La única vez que saltó esa disciplina, un cambio incompatible salió etiquetado como parche y le costó un hilo de soporte que podría haber evitado.
El autor, que firma como RAXXO Studios, cuenta que al principio pensaba que el versionado era cosa de equipos, no de alguien que trabaja solo con cinco productos en producción. Pero cuando un cliente que compró hace ocho meses y abre la herramienta dos veces al año pregunta qué cambió, el número de versión es la única respuesta honesta que puede dar sin escribir un mensaje personal a cada usuario.
La regla y su valor
La regla es simple: un parche no cambia nada salvo arreglar algo roto; una versión menor añade capacidad sin quitar ni alterar lo que ya funcionaba; una mayor puede romper cosas, a propósito y con aviso. El valor no está en conocer la regla — muchos desarrolladores la saben — sino en no caer en la tentación de saltársela porque un cambio parece pequeño en el momento.
El autor compara el changelog y el número de versión: son el mismo compromiso escrito dos veces. Una entrada de changelog sin versión es un diario; un número sin changelog es un número que nadie puede usar. Solo funcionan como par, y considera una release inacabada hasta que existen ambos.
También hay una razón personal: al mantener varios proyectos solo, el versionado le sirve de ayuda de memoria. Cuando abre un repositorio que lleva semanas sin tocar y ve que está en 2.4.1, sabe que ha habido un cambio desde el lanzamiento y que desde entonces solo ha habido añadidos y correcciones. Reconstruir eso con la historia de commits en frío llevaría más tiempo.
El fallo que vigila más de cerca
El modo de fallo que más vigila es el del parche que silenciosamente hace más de lo que dice. Es fácil: estás arreglando una cosa, ves otra cerca que podría mejorar y te entra la tentación de incluirla en la misma release porque ya estás tocando ese archivo. Ya no se lo permite: 'pequeña mejora' y 'ningún comportamiento cambiado' no son lo mismo, y un parche promete solo lo segundo.
La prueba que aplica antes de etiquetar algo como parche es contundente: ¿podría un usuario con automatización construida sobre el comportamiento actual actualizar y que esa automatización haga algo distinto en silencio? Si la respuesta honesta es 'quizás', no es un parche, por pequeño que se vea el diff.
Esto importa más en las herramientas con API o interfaz scriptable, donde el código de otro depende de que el comportamiento de hoy siga mañana. Las versiones menores tienen más margen, pero no ilimitado: añadir un ajuste nuevo, una opción de exportación o una vista nueva está bien, siempre que la herramienta se comporte igual para quien ignore la nueva capacidad.
El momento en que una nueva función cambia un valor por defecto, o cambia lo que pasa cuando el usuario no hace nada distinto, esa promesa aditiva se rompe y el cambio pertenece a una versión mayor. Aplica la misma prueba a las actualizaciones de dependencias: subir una librería puede ser un parche si se ha verificado que no altera el comportamiento observable, pero es fácil querer colar una actualización de librería 'de paso' en una release que debería ser solo un bugfix. El mantenimiento que puede alterar salida, tiempos o errores no está exento de la regla solo porque no provenga de su propio código.
El autor también reconoce los límites de esta disciplina: el número de versión no dice nada sobre la urgencia de una release, la gravedad del bug o si una versión menor incluye lo que un usuario esperaba desde hace meses. El número describe la forma del riesgo al actualizar, no el tamaño del beneficio. Y un parche correctamente etiquetado que aún tiene un bug sigue siendo un bug; llamarlo parche no hace el error más pequeño.
