El panel interno de releases era una tontería honrada: un desplegable con las versiones de un paquete propio y, debajo, el changelog de la que eligieras. Se montó en una tarde y funcionó seis meses. Hasta que alguien preguntó por qué arriba del todo salía la 1.9.0 si esa misma semana habíamos publicado la 1.10.0.
El culpable estaba a la vista: un sort() a secas. Orden alfabético. Y en alfabético, «1.10.0» va antes que «1.9.0», porque compara el «1» con el «9» y ahí se acaba la historia. Medio año de releases ordenadas mal y nadie lo vio, porque hasta la 1.9 el orden alfabético y el numérico coinciden. El bug estaba esperando a que llegara la décima minor.
El arreglo obvio dura cuatro versiones
Partir por puntos, convertir a número, comparar de izquierda a derecha. Quince líneas. Aguanta perfectamente… hasta que aparece la 2.0.0-rc.1 y el comparador la deja empatada con la 2.0.0.
Dónde ayudó de verdad la IA local
Le pedí el comparador al modelo del IDE y lo primero que devolvió fueron, exactamente, las quince líneas que yo ya tenía. Lo útil vino después, cuando le pegué mis etiquetas: la lista de tags tal cual sale del repositorio, con sus -rc, sus -beta.2, un par de +build y tres tags viejos con el nombre de un cliente metido dentro. Con los datos reales delante, la pregunta dejó de ser «escríbeme un comparador» y pasó a ser «estos veinte, ¿en qué orden van y por qué?».
Salieron las reglas que uno nunca recuerda de memoria:
- Una pre-release va antes que su versión final: 2.0.0-rc.1 < 2.0.0. Es lo contrario de lo que sugiere la intuición de «tiene más cosas escritas, será mayor».
- Dentro de la pre-release, los identificadores numéricos se comparan como números y los alfanuméricos como texto. O sea: el mismo bug del principio, un piso más abajo, esperando en rc.10 contra rc.2.
- El metadato de build (+build.412) no cuenta para ordenar. Pero sí cuenta si lo que quieres es saber si dos cadenas son «la misma versión».
- Si todo lo demás empata, gana el que tiene menos campos: 1.0.0-alpha < 1.0.0-alpha.1.
De ahí salió una tabla de casos, y de la tabla salieron los tests: veintitantas parejas, cada una con su porqué escrito al lado. El comparador final son unas cuarenta líneas. Lo caro no fue escribirlo, fue saber qué tenía que hacer.
Por qué esto no se pega en un chat ajeno
La lista de tags de un repo privado es un documento con información dentro: cuándo arrancó un proyecto, cómo se llama la rama de un cliente que nunca se anunció, qué versión se quedó en rc para siempre. Nada de eso es un secreto industrial, pero tampoco tiene por qué quedarse en el historial de un servicio de terceros solo para ordenar veinte cadenas.
Sin tus datos, la IA escribe un comparador genérico. Con ellos, escribe el tuyo. Y la diferencia es justo lo que no te apetece subir a ninguna parte.
Abre Elffuss Code y pégale tus veinte casos de verdad, sin recortar nada: el modelo corre entero dentro del navegador, así que ni tu código ni tus datos salen de tu máquina.
Abrir Code →