Cuatro releases en veintiséis horas: fontanería de idiomas y una "bridge release"

Entre un jueves por la mañana y un viernes por la tarde de febrero de 2026, GeekBye publicó cuatro releases: v1.7.6, v1.7.7, v1.8.0 y v1.8.1 — dieciséis commits, unas veintiséis horas entre el primer tag y el último. Ninguna de ellas es un titular por sí sola. Juntas son un retrato de lo que contienen de verdad las semanas de releases pequeñas: una feature que por fin termina su viaje, un overlay de calidad de vida, un número de versión sin código dentro y una pieza de release engineering genuinamente instructiva.

El idioma que nunca salió del portátil

GeekBye tiene un ajuste de idioma de transcripción desde septiembre de 2025. Funcionaba — localmente. Elige español y el pipeline de speech-to-text en el dispositivo transcribía español obedientemente. Pero haz grep del código de v1.7.5 buscando ese ajuste y lo encuentras exactamente en tres sitios: el manejador de audio, la UI de Settings y el hook de settings. No en el cliente de API. No en el tracker de sesiones. Durante cuatro meses, cada petición que salía de la máquina era ciega al idioma: los registros de sesión del backend no tenían ni idea de qué idioma representaban, y el chat de IA recibía transcripciones en español sin ninguna pista de que estaban en español.

v1.7.6 es la release en la que el ajuste terminó su viaje — dos commits, un día. El arranque de la sesión de audio ahora lleva transcriptLanguage en su payload, y la petición de stream-chat de la IA ganó el mismo campo, enhebrado a través de un pequeño helper que lee el ajuste y devuelve deliberadamente undefined cuando es auto o no está definido, de modo que los backends antiguos degradan con elegancia en vez de atragantarse con un campo que no conocen. Hay además un arreglo extra escondido discretamente en el diff: para pasar el idioma, el arranque de sesión tuvo que moverse después de la resolución del idioma — lo que, según lo leemos, también cerró una ruta de error en la que una sesión podía arrancarse (y contarse contra los límites) y quedar huérfana cuando la resolución del idioma fallaba un instante después.

La lección generaliza: un ajuste no está publicado cuando tiene una UI y un efecto. Está publicado cuando llega a cada consumidor que debería conocerlo. El nuestro se detuvo en la frontera de la red durante cuatro meses, y nadie lo notó, porque el comportamiento local — el comportamiento visible — fue correcto todo el tiempo. (Esta fue la primera pasada, tosca, del manejo de idiomas, que conste; enseñar a la IA a responder de verdad en el idioma de la conversación es un capítulo muy posterior de esta historia.)

Cmd+/ — un overlay que no miente sobre tus keybindings

La feature de cara al usuario de v1.8.0 es un overlay de atajos de teclado en Cmd+/ — 193 líneas de componente nuevo, y una decisión de diseño que vale la pena robar: no renderiza una chuleta hardcodeada. Obtiene la configuración de atajos en vivo y renderiza customKeys || defaultKeys, de modo que un usuario que remapeó sus teclas ve sus teclas. Un overlay de atajos que muestra los valores por defecto a alguien que los cambió no es documentación; es desinformación con buena tipografía.

El resto son pequeños toques de corrección: el overlay se posiciona a la izquierda o a la derecha de la tarjeta de la app según qué lado de la pantalla tiene sitio, y se cierra con Escape, con Cmd+/ otra vez o con un clic fuera. El propio Cmd+/ se une al mismo sistema de presets remapeables que cualquier otro atajo — lo cual importa, porque Cmd+/ es «comentar/descomentar» en la mayoría de editores, y una herramienta para desarrolladores no debería ocupar una tecla del editor que no puedas mover.

La «bridge release»

La ingeniería interesante ocurrió en los números de versión que nadie miraría dos veces. v1.8.0 también migró las releases del proyecto a una nueva organización de GitHub — limpieza organizativa en la superficie, salvo por una propiedad del auto-update de escritorio: la URL del feed va horneada en el binario. Cada instalación de v1.8.0 consulta las releases de la nueva organización. Y cada instalación ahí fuera — todas v1.7.7 o anteriores — consulta la antigua, para siempre, a menos que algo aparezca allí.

Ese es el huevo y la gallina: publica tu siguiente release solo en el repo nuevo y la flota existente entera no la verá jamás. Dieciséis minutos después del tag de v1.8.0, aterrizó un flag nuevo en el script de release: --publish-owner, que reescribe dónde sube electron-builder los artefactos después del build — explícitamente «sin afectar al código compilado de la app», como dice el comentario en el código. Ese es todo el truco, y es exactamente la costura correcta: el feed horneado en el binario y el destino de subida de los artefactos son dos decisiones distintas, y una migración necesita desacoplarlas durante una release. Construye v1.8.1 apuntando al feed nuevo, súbela al repo antiguo; los clientes antiguos ven la actualización allí, la instalan y despiertan consultando la organización nueva. El mensaje de commit llama a esto una «bridge release» (release puente), que es el nombre correcto. v1.8.1 se etiquetó dos horas y veinte minutos después de v1.8.0. (Para la historia de origen de por qué este proyecto trata el auto-update con un respeto que roza el miedo, ver el auto-update que hizo a nuestra app imposible de matar.)

¿Y v1.7.7? Un commit. El propio bump de versión. Sin arreglo, sin revert, sin explicación en el historial — nuestra mejor lectura es un publish que hubo que relanzar, y preferimos admitirlo antes que inventar una historia. A veces un número de versión existe porque publicar software es un proceso del mundo real con tropiezos del mundo real, no una función pura del árbol de código. En cuanto a por qué 1.7 pasó a ser 1.8: ningún commit lo dice, pero la migración del feed es la frontera de compatibilidad significativa — cada binario 1.8.x mira a una organización distinta que cada binario 1.7.x — y eso merece un bump minor más que cualquier feature.

Tres cosas que nos enseñó esta semana

1. Rastrea un ajuste hasta cada consumidor. La preferencia de idioma estuvo «terminada» durante cuatro meses mientras el backend seguía ciego. Que el comportamiento local y visible fuera correcto es exactamente lo que permitió que el hueco sobreviviera — la pregunta de auditoría es «¿quién más debería conocer este valor?», formulada en cada frontera.
2. Renderiza la configuración en vivo, no documentación. El overlay de atajos lee la misma fuente de verdad que usa el sistema de atajos. Cualquier otra cosa se desvía la primera vez que un usuario personaliza.
3. Una migración de feed necesita una release que viva en ambos mundos. Feed nuevo en el binario, repo antiguo para la subida. Si tu tooling de release no puede separar esos dos destinos, añade el flag antes de necesitarlo — el nuestro llegó dieciséis minutos después de hacer falta, que es lo bastante cerca como para contar.

Para el capítulo anterior de la historia v1, la página de login ES la demo (v1.7.5); y para todo el arco, la anatomía de publicar software hasta la perfección.