Quatre releases en vingt-six heures : plomberie de langue et une « bridge release »

Entre un jeudi matin et un vendredi après-midi de février 2026, GeekBye a livré quatre releases : v1.7.6, v1.7.7, v1.8.0 et v1.8.1 — seize commits, environ vingt-six heures entre le premier tag et le dernier. Aucune d'elles ne fait la une à elle seule. Ensemble, elles sont un portrait de ce que contiennent vraiment les semaines de petites releases : une feature qui termine enfin son voyage, un overlay de confort, un numéro de version sans code dedans, et un morceau de release engineering authentiquement instructif.

La langue qui n'a jamais quitté le laptop

GeekBye a un réglage de langue de transcription depuis septembre 2025. Il fonctionnait — localement. Choisissez l'espagnol et le pipeline de speech-to-text local transcrivait consciencieusement de l'espagnol. Mais faites un grep du code de v1.7.5 pour ce réglage et vous le trouvez à exactement trois endroits : le handler audio, l'UI des Settings et le hook de settings. Pas dans le client API. Pas dans le tracker de sessions. Pendant quatre mois, chaque requête qui quittait la machine était aveugle à la langue : les enregistrements de session côté backend n'avaient aucune idée de la langue qu'ils représentaient, et le chat IA recevait des transcriptions en espagnol sans le moindre indice qu'elles étaient en espagnol.

v1.7.6 est la release où le réglage a terminé son voyage — deux commits, une journée. Le démarrage de la session audio porte maintenant transcriptLanguage dans son payload, et la requête de stream-chat de l'IA a gagné le même champ, tissé à travers un petit helper qui lit le réglage et renvoie délibérément undefined quand il vaut auto ou n'est pas défini, de sorte que les backends plus anciens dégradent gracieusement au lieu de s'étrangler sur un champ qu'ils ne connaissent pas. Il y a aussi un correctif bonus discrètement caché dans le diff : pour passer la langue, le démarrage de session a dû se déplacer après la résolution de la langue — ce qui, tel que nous le lisons, a aussi fermé un chemin d'erreur où une session pouvait être démarrée (et décomptée des limites) puis orpheline quand la résolution de la langue échouait un instant plus tard.

La leçon se généralise : un réglage n'est pas livré quand il a une UI et un effet. Il est livré quand il atteint chaque consommateur qui devrait le connaître. Le nôtre s'est arrêté à la frontière du réseau pendant quatre mois, et personne ne l'a remarqué, parce que le comportement local — le comportement visible — était correct tout du long. (C'était la première passe, grossière, de la gestion des langues, pour mémoire ; apprendre à l'IA à réellement répondre dans la langue de la conversation est un chapitre bien plus tardif de cette histoire.)

Cmd+/ — un overlay qui ne ment pas sur vos keybindings

La feature visible de v1.8.0 est un overlay de raccourcis clavier sur Cmd+/ — 193 lignes de composant neuf, et une décision de design qui vaut la peine d'être volée : il ne rend pas un aide-mémoire codé en dur. Il récupère la configuration de raccourcis en direct et rend customKeys || defaultKeys, si bien qu'un utilisateur qui a remappé ses touches voit ses touches. Un overlay de raccourcis qui montre les valeurs par défaut à quelqu'un qui les a changées n'est pas de la documentation ; c'est de la désinformation avec une belle typographie.

Le reste, ce sont de petites touches de justesse : l'overlay se positionne à gauche ou à droite de la carte de l'app selon le côté de l'écran qui a de la place, et se ferme sur Escape, sur Cmd+/ à nouveau, ou sur un clic à l'extérieur. Cmd+/ lui-même rejoint le même système de presets remappables que tous les autres raccourcis — ce qui compte, parce que Cmd+/ est « commenter/décommenter » dans la plupart des éditeurs, et un outil pour développeurs ne devrait pas squatter une touche d'éditeur qu'on ne peut pas déplacer.

La « bridge release »

L'ingénierie intéressante s'est jouée dans les numéros de version que personne ne regarderait deux fois. v1.8.0 a aussi migré les releases du projet vers une nouvelle organisation GitHub — du rangement d'org en surface, à un détail près, propre à l'auto-update desktop : l'URL du feed est embarquée dans le binaire. Chaque installation de v1.8.0 interroge les releases de la nouvelle organisation. Et chaque installation dans la nature — toutes en v1.7.7 ou antérieur — interroge l'ancienne, pour toujours, à moins que quelque chose y apparaisse.

C'est ça, la poule et l'œuf : publiez votre prochaine release uniquement sur le nouveau dépôt et toute la flotte existante ne la verra jamais. Seize minutes après le tag v1.8.0, un nouveau flag a atterri dans le script de release : --publish-owner, qui réécrit où electron-builder uploade les artefacts après le build — explicitement « sans affecter le code compilé de l'app », comme le dit le commentaire dans le code. C'est tout le truc, et c'est exactement la bonne couture : le feed embarqué dans le binaire et la destination d'upload des artefacts sont deux décisions différentes, et une migration a besoin de les découpler le temps d'une release. Construisez v1.8.1 pointant vers le nouveau feed, uploadez-la vers l'ancien dépôt ; les anciens clients voient la mise à jour là-bas, l'installent, et se réveillent en interrogeant la nouvelle organisation. Le message de commit appelle ça une « bridge release » (release passerelle), et c'est le bon nom. v1.8.1 a été taggée deux heures et vingt minutes après v1.8.0. (Pour l'histoire d'origine de pourquoi ce projet traite l'auto-update avec un respect qui frôle la peur, voir l'auto-update qui a rendu notre app intuable.)

Et v1.7.7 ? Un commit. Le bump de version lui-même. Pas de correctif, pas de revert, pas d'explication dans l'historique — notre meilleure lecture est un publish qu'il a fallu relancer, et nous préférons l'admettre plutôt qu'inventer une histoire. Parfois un numéro de version existe parce que publier du logiciel est un processus du monde réel avec des ratés du monde réel, pas une fonction pure de l'arbre source. Quant à savoir pourquoi 1.7 est devenu 1.8 : aucun commit ne le dit, mais la migration du feed est la vraie frontière de compatibilité — chaque binaire 1.8.x regarde une organisation différente de chaque binaire 1.7.x — et ça mérite un bump minor plus que n'importe quelle feature.

Trois choses que cette semaine nous a apprises

1. Tracez un réglage jusqu'à chaque consommateur. La préférence de langue était « terminée » depuis quatre mois pendant que le backend restait aveugle. Le comportement local, visible, étant correct est exactement ce qui a permis à l'écart de survivre — la question d'audit est « qui d'autre devrait connaître cette valeur ? », posée à chaque frontière.
2. Rendez la config en direct, pas de la documentation. L'overlay de raccourcis lit la même source de vérité que le système de raccourcis. Tout le reste dérive dès qu'un utilisateur personnalise.
3. Une migration de feed a besoin d'une release qui vit dans les deux mondes. Nouveau feed dans le binaire, ancien dépôt pour l'upload. Si votre tooling de release ne sait pas séparer ces deux cibles, ajoutez le flag avant d'en avoir besoin — le nôtre est arrivé seize minutes après qu'on en a eu besoin, ce qui est assez proche pour compter.

Pour le chapitre précédent de l'histoire v1, la page de login EST la démo (v1.7.5) ; et pour tout l'arc, l'anatomie de livrer un logiciel jusqu'à la perfection.