De dónde salen los números de versión (y por qué vuelven los bugs)
Cuando un programa dice versión 2.3.1, ¿de dónde sale cada uno de esos números?
Leyendo sobre esto me encontré un artículo de Vincent Driessen donde explica cómo trabaja su equipo con ramas. Voy a contarlo con un libro en vez de con código, porque funciona igual y se entiende mejor.
Una advertencia antes de empezar: lo que sigue es mi lectura de ese artículo, no el estándar de versionado semántico. En SemVer los tres números significan otra cosa —cambios incompatibles, funcionalidad nueva y correcciones—. Lo que describo aquí es un flujo de trabajo, y de él salen tres numeritos que se le parecen sin ser lo mismo.
Las ramas
La rama pública. Siempre, siempre, siempre es un producto terminado. Un capítulo completo, una característica completa, una versión estable, fija y funcional. Algo que se pueda leer de principio a fin. Tal vez no perfecto, pero útil.
(En git se llama master. Hoy la convención se movió a main.)
La rama de desarrollo. Es fija, y es donde trabajas constantemente: el siguiente capítulo, la siguiente característica, los botones nuevos. Todo lo que está en tu plan principal.
Las ramas de prueba. Temporales. Son esas ideas que te llegan de repente: ¿qué tal si pongo esta pequeña carta dentro de este capítulo, de uno de mis personajes? Haces la rama, trabajas ahí. Si funciona, la regresas a desarrollo. Si no funciona, la borras. De preferencia bórrala de verdad, porque si no acabas con un montón de cosas que nunca vas a usar.
La rama de liberación. Cuando llegas a una meta, separas lo que vas a publicar. Le das ese capítulo nuevo a varias personas para que revisen la ortografía, para que revisen si tiene sentido lo que escribiste. Es tu primera versión del producto final, y va a prueba de todo.
Las ramas de corrección urgente. Cuando la versión pública está mal: algo que hace que el programa no sirva, o una tontería en tu libro que hace que la gente no lo lea. Sale de la rama pública, se corrige rápido, y regresa.
Los cambios cosméticos. Cosas que sí mejoran, pero que si no están, tampoco se muere el proyecto.
Y ahora los tres numeritos
El primero sube cuando una versión de liberación pasa a la rama pública. Es un producto nuevo, revisado, con las características que querías.
El segundo —2.1, 2.2, 2.3— lo crean las correcciones urgentes. Esperemos no llegar a tantos, porque eso significa que nos equivocamos mucho.
El tercero —1.2.1, 1.2.2— son los cambios cosméticos. Cosas que incrementan la calidad y que, si no están, no afectan la intención de lo que hiciste.
La regla que casi todos olvidan
Y aquí está la parte importante de todo esto.
Cada vez que corriges algo en la rama pública, acuérdate de pasar ese cambio también a la rama de desarrollo.
Suena a detalle burocrático. No lo es, y ésta es la razón:
Mientras tú corregías el error en público, otras personas seguían trabajando en desarrollo, sobre una copia que todavía tiene el error. Cuando esa rama madure y se libere, va a sobrescribir tu corrección.
Por eso te ha pasado que corrigen algo, ya funciona bien, después actualizas, y otra vez está ese mismo error. El mismo, ni siquiera uno nuevo.
No es mala suerte ni descuido puntual: es no tener un buen flujo de trabajo.
Por qué Windows te manda parches todo el rato
El otro efecto visible de todo esto.
Se sacan versiones al público muy rápido, tal vez sin tantas pruebas, o simplemente porque no se puede probar en tantos dispositivos. Windows lo usan muchísimas máquinas distintas y nadie sabe cómo va a reaccionar el programa en la computadora de alguien más.
Y cuando se dan cuenta, empiezan a meter parches: correcciones que sí son importantes y de las que no se habían enterado, porque a ellos no les fallaba.
De ahí las actualizaciones constantes de un programa que supuestamente ya estaba terminado.
Este texto sale del episodio 014 del Podcast Algoritmos, sobre git para quien no programa.