
Quattro release in ventisei ore: idraulica delle lingue e una "bridge release"
GeekBye dalla v1.7.6 alla v1.8.1: un'impostazione della lingua che non aveva mai lasciato il laptop, un overlay su Cmd+/ che mostra i tuoi keybinding reali, una versione con zero modifiche al codice — e l'uovo e la gallina della migrazione del feed di auto-update.
Tra un giovedì mattina e un venerdì pomeriggio di febbraio 2026, GeekBye ha spedito quattro release: v1.7.6, v1.7.7, v1.8.0 e v1.8.1 — sedici commit, circa ventisei ore tra il primo tag e l'ultimo. Nessuna di loro fa notizia da sola. Insieme sono un ritratto di cosa contengono davvero le settimane di piccole release: una feature che finalmente completa il suo viaggio, un overlay di qualità della vita, un numero di versione senza codice dentro e un pezzo di release engineering genuinamente istruttivo.
La lingua che non ha mai lasciato il laptop
GeekBye ha un'impostazione per la lingua di trascrizione da settembre 2025. Funzionava — localmente. Scegli spagnolo e la pipeline di speech-to-text on-device trascriveva diligentemente in spagnolo. Ma fai un grep della codebase v1.7.5 per quell'impostazione e la trovi esattamente in tre posti: il gestore audio, la UI delle Settings e l'hook delle impostazioni. Non nel client API. Non nel tracker delle sessioni. Per quattro mesi, ogni richiesta che lasciava la macchina era cieca alla lingua: i record di sessione del backend non avevano idea di quale lingua rappresentassero, e la chat IA riceveva trascrizioni in spagnolo senza alcun indizio che fossero in spagnolo.
La v1.7.6 è la release in cui l'impostazione ha completato il suo viaggio — due commit, un giorno. L'avvio della sessione audio ora porta transcriptLanguage nel suo payload, e la richiesta di stream-chat dell'IA ha guadagnato lo stesso campo, fatto passare attraverso un piccolo helper che legge l'impostazione e restituisce deliberatamente undefined quando è auto o non impostata, così i backend più vecchi degradano con grazia invece di strozzarsi su un campo che non conoscono. C'è anche un fix bonus nascosto in silenzio nel diff: per passare la lingua, l'avvio della sessione ha dovuto spostarsi dopo la risoluzione della lingua — il che, per come lo leggiamo, ha anche chiuso un percorso di errore in cui una sessione poteva essere avviata (e contata contro i limiti) e poi restare orfana quando la risoluzione della lingua falliva un istante dopo.
La lezione si generalizza: un'impostazione non è spedita quando ha una UI e un effetto. È spedita quando raggiunge ogni consumatore che dovrebbe conoscerla. La nostra si è fermata al confine della rete per quattro mesi, e nessuno se n'è accorto, perché il comportamento locale — il comportamento visibile — è stato corretto per tutto il tempo. (Questa è stata la prima passata, grezza, della gestione delle lingue, per la cronaca; insegnare all'IA a rispondere davvero nella lingua della conversazione è un capitolo molto successivo di questa storia.)
Cmd+/ — un overlay che non mente sui tuoi keybinding
La feature rivolta all'utente della v1.8.0 è un overlay di scorciatoie da tastiera su Cmd+/ — 193 righe di componente nuovo, e una decisione di design che vale la pena rubare: non renderizza un bigino hardcoded. Recupera la configurazione delle scorciatoie dal vivo e renderizza customKeys || defaultKeys, così un utente che ha rimappato i suoi tasti vede i suoi tasti. Un overlay di scorciatoie che mostra i default a qualcuno che li ha cambiati non è documentazione; è disinformazione con una bella tipografia.
Il resto sono piccoli tocchi di correttezza: l'overlay si posiziona a sinistra o a destra della card dell'app a seconda di quale lato dello schermo ha spazio, e si chiude con Escape, con Cmd+/ di nuovo o con un clic fuori. Lo stesso Cmd+/ entra nello stesso sistema di preset rimappabili di ogni altra scorciatoia — il che conta, perché Cmd+/ è «commenta/decommenta» nella maggior parte degli editor, e uno strumento per sviluppatori non dovrebbe occupare un tasto dell'editor che non puoi spostare.
La «bridge release»
L'ingegneria interessante è avvenuta nei numeri di versione che nessuno guarderebbe due volte. La v1.8.0 ha anche migrato le release del progetto in una nuova organizzazione GitHub — pulizia organizzativa in superficie, se non fosse per una proprietà dell'auto-update desktop: l'URL del feed è cotto nel binario. Ogni installazione della v1.8.0 interroga le release della nuova organizzazione. E ogni installazione là fuori — tutte v1.7.7 o precedenti — interroga quella vecchia, per sempre, a meno che qualcosa non compaia lì.
Ecco l'uovo e la gallina: pubblica la tua prossima release solo sul repo nuovo e l'intera flotta esistente non la vedrà mai. Sedici minuti dopo il tag v1.8.0, un nuovo flag è atterrato nello script di release: --publish-owner, che riscrive dove electron-builder carica gli artefatti dopo la build — esplicitamente «senza toccare il codice compilato dell'app», come dice il commento nel codice. È tutto il trucco, ed è esattamente la giuntura giusta: il feed cotto nel binario e la destinazione di upload degli artefatti sono due decisioni diverse, e una migrazione ha bisogno che siano disaccoppiate per una release. Costruisci la v1.8.1 puntata sul feed nuovo, caricala sul repo vecchio; i client vecchi vedono l'aggiornamento lì, lo installano e si svegliano interrogando la nuova organizzazione. Il messaggio di commit chiama tutto questo una «bridge release» (release ponte), che è il nome giusto. La v1.8.1 è stata taggata due ore e venti minuti dopo la v1.8.0. (Per la storia delle origini del perché questo progetto tratta l'auto-update con un rispetto che rasenta la paura, vedi l'auto-update che ha reso la nostra app impossibile da uccidere.)
E la v1.7.7? Un commit. Il bump di versione stesso. Nessun fix, nessun revert, nessuna spiegazione nella cronologia — la nostra lettura migliore è un publish che è stato necessario rilanciare, e preferiamo ammetterlo piuttosto che inventare una storia. A volte un numero di versione esiste perché rilasciare software è un processo del mondo reale con singhiozzi del mondo reale, non una funzione pura dell'albero dei sorgenti. Quanto al perché 1.7 sia diventato 1.8: nessun commit lo dice, ma la migrazione del feed è il confine di compatibilità significativo — ogni binario 1.8.x guarda a un'organizzazione diversa da ogni binario 1.7.x — e questo merita un bump minor più di qualsiasi feature.
Tre cose che questa settimana ci ha insegnato
- Traccia un'impostazione fino a ogni consumatore. La preferenza della lingua è stata «finita» per quattro mesi mentre il backend restava cieco. Il fatto che il comportamento locale e visibile fosse corretto è esattamente ciò che ha permesso al buco di sopravvivere — la domanda di audit è «chi altro dovrebbe conoscere questo valore?», posta a ogni confine.
- Renderizza la configurazione dal vivo, non la documentazione. L'overlay delle scorciatoie legge la stessa fonte di verità usata dal sistema delle scorciatoie. Qualsiasi altra cosa va alla deriva la prima volta che un utente personalizza.
- Una migrazione di feed ha bisogno di una release che viva in entrambi i mondi. Feed nuovo nel binario, repo vecchio per l'upload. Se il tuo tooling di release non sa separare quei due bersagli, aggiungi il flag prima di averne bisogno — il nostro è arrivato sedici minuti dopo che serviva, che è abbastanza vicino da contare.
Per il capitolo precedente della storia v1, la pagina di login È la demo (v1.7.5); e per tutto l'arco, l'anatomia del pubblicare software fino alla perfezione.