
Fire releaser på tjueseks timer: språk-rørlegging og en "bridge release"
GeekBye v1.7.6 til v1.8.1: en språkinnstilling som aldri hadde forlatt laptopen, en Cmd+/-overlay som viser dine ekte tastebindinger, en versjon med null kodeendringer — og høna-og-egget i å migrere auto-update-feeden sin.
Mellom en torsdag morgen og en fredag ettermiddag i februar 2026 shippet GeekBye fire releaser: v1.7.6, v1.7.7, v1.8.0 og v1.8.1 — seksten commits, omtrent tjueseks timer mellom første tag og siste. Ingen av dem er en overskrift alene. Sammen er de et portrett av hva små-release-uker faktisk inneholder: en feature som endelig fullfører reisen sin, en quality-of-life-overlay, et versjonsnummer uten kode i seg, og ett genuint lærerikt stykke release engineering.
Språket som aldri forlot laptopen
GeekBye har hatt en innstilling for transkriptspråk siden september 2025. Den fungerte — lokalt. Velg spansk, og den lokale tale-til-tekst-pipelinen transkriberte pliktoppfyllende spansk. Men grep v1.7.5-kodebasen etter den innstillingen, og du finner den på nøyaktig tre steder: audio-handleren, Settings-UI-et og settings-hooken. Ikke i API-klienten. Ikke i sesjonstrackeren. I fire måneder var hver request som forlot maskinen språkblind: backendens sesjonsposter ante ikke hvilket språk de representerte, og AI-chatten mottok spanske transkripter uten hint om at de var spanske.
v1.7.6 er releasen der innstillingen fullførte reisen sin — to commits, én dag. Audiosesjonens start bærer nå transcriptLanguage i payloaden sin, og AI-ens stream-chat-request fikk samme felt, tredd gjennom en liten hjelpefunksjon som leser innstillingen og bevisst returnerer undefined når den er auto eller ikke satt, slik at eldre backends degraderer pent i stedet for å sette et ukjent felt i halsen. Det gjemmer seg også en stille bonusfiks i diffen: for å kunne sende med språket måtte sesjonsstarten flyttes til etter språkoppløsningen — noe som, slik vi leser det, også lukket en feilsti der en sesjon kunne startes (og telles mot limits) og deretter bli foreldreløs når språkoppløsningen feilet et øyeblikk senere.
Lærdommen generaliserer: en innstilling er ikke shippet når den har et UI og en effekt. Den er shippet når den når hver konsument som burde kjenne til den. Vår stoppet ved nettverksgrensen i fire måneder, og ingen la merke til det, fordi den lokale oppførselen — den synlige oppførselen — var korrekt hele tiden. (Dette var det grove første forsøket på språkhåndtering, for ordens skyld; å lære AI-en å faktisk svare på samtalens språk er et mye senere kapittel i denne historien.)
Cmd+/ — en overlay som ikke lyver om tastebindingene dine
v1.8.0s brukervendte feature er en snarveisoverlay på Cmd+/ — 193 linjer ny komponent, og én designbeslutning verdt å stjele: den rendrer ikke et hardkodet jukseark. Den henter den levende snarveiskonfigurasjonen og rendrer customKeys || defaultKeys, så en bruker som har remappet tastene sine, ser sine taster. En snarveisoverlay som viser defaults til noen som har endret dem, er ikke dokumentasjon; det er feilinformasjon med pen typografi.
Resten er små korrekthetdetaljer: overlayen plasserer seg til venstre eller høyre for app-kortet avhengig av hvilken side av skjermen som har plass, og lukkes på Escape, på Cmd+/ igjen eller på et klikk utenfor. Cmd+/ selv går inn i det samme remapbare preset-systemet som enhver annen snarvei — noe som betyr noe, for Cmd+/ er "toggle comment" i de fleste editorer, og et verktøy for utviklere bør ikke okkupere en editortast du ikke kan flytte.
Bridge-releasen
Den interessante ingeniørkunsten skjedde i versjonsnumrene ingen ville sett to ganger på. v1.8.0 migrerte også prosjektets releaser til en ny GitHub-organisasjon — org-rydding på overflaten, om det ikke var for én egenskap ved desktop-auto-update: feed-URL-en er bakt inn i binæren. Hver v1.8.0-installasjon poller den nye organisasjonens releaser. Og hver installasjon der ute i verden — alle sammen v1.7.7 eller eldre — poller den gamle, for alltid, med mindre noe dukker opp der.
Det er høna-og-egget: publiser neste release kun til det nye repoet, og hele den eksisterende flåten ser den aldri. Seksten minutter etter v1.8.0-taggen landet et nytt flagg i release-scriptet: --publish-owner, som skriver om hvor electron-builder laster opp artefaktene, etter bygget — eksplisitt "uten å påvirke den kompilerte appkoden", som kodekommentaren formulerer det. Det er hele trikset, og det er akkurat riktig søm: binærens innbakte feed og artefaktenes opplastingsdestinasjon er to forskjellige beslutninger, og en migrering trenger dem frikoblet i én release. Bygg v1.8.1 pekende mot den nye feeden, last den opp til det gamle repoet; gamle klienter ser oppdateringen der, installerer den og våkner opp pollende den nye organisasjonen. Commit-meldingen kaller dette en "bridge release", som er riktig navn. v1.8.1 ble tagget to timer og tjue minutter etter v1.8.0. (For opprinnelseshistorien om hvorfor dette prosjektet behandler auto-update med en respekt som grenser til frykt, se auto-oppdateringen som gjorde appen vår udrepelig.)
Og v1.7.7? Én commit. Selve versjonsbumpen. Ingen fiks, ingen revert, ingen forklaring i historikken — vår beste lesning er en publisering som måtte kjøres på nytt, og det innrømmer vi heller enn å finne på en historie. Noen ganger finnes et versjonsnummer fordi det å utgi programvare er en virkelighetsprosess med virkelighetshikke, ikke en ren funksjon av kildetreet. Når det gjelder hvorfor 1.7 i det hele tatt ble 1.8: ingen commit sier det, men feed-migreringen er den meningsfulle kompatibilitetsgrensen — hver 1.8.x-binær ser mot en annen organisasjon enn hver 1.7.x-binær — og det fortjener en minor-bump mer enn noen feature gjør.
Tre ting denne uken lærte oss
- Spor en innstilling til hver konsument. Språkpreferansen var "ferdig" i fire måneder mens backenden forble blind. At den synlige, lokale oppførselen var korrekt, er nøyaktig det som lot gapet overleve — revisjonsspørsmålet er "hvem andre burde kjenne til denne verdien?", stilt ved hver grense.
- Render levende konfigurasjon, ikke dokumentasjon. Snarveisoverlayen leser den samme kilden til sannhet som snarveissystemet bruker. Alt annet driver ut av synk første gang en bruker tilpasser noe.
- En feed-migrering trenger én release som lever i begge verdener. Ny feed i binæren, gammelt repo for opplastingen. Hvis release-verktøyet ditt ikke kan skille de to målene, legg til flagget før du trenger det — vårt ankom seksten minutter etter at det trengtes, som er nært nok til å telle.
For det forrige kapittelet i v1-historien, innloggingssiden ER demoen (v1.7.5); og for hele buen, anatomien i å shippe programvare til perfeksjon.