Vier Releases in sechsundzwanzig Stunden: Sprach-Verrohrung und ein „Bridge Release"

Zwischen einem Donnerstagmorgen und einem Freitagnachmittag im Februar 2026 lieferte GeekBye vier Releases aus: v1.7.6, v1.7.7, v1.8.0 und v1.8.1 — sechzehn Commits, rund sechsundzwanzig Stunden zwischen dem ersten Tag und dem letzten. Keines davon taugt allein zur Schlagzeile. Zusammen sind sie ein Porträt dessen, was Wochen mit kleinen Releases tatsächlich enthalten: ein Feature, das endlich seine Reise beendet, ein Quality-of-Life-Overlay, eine Versionsnummer ohne Code darin — und ein wirklich lehrreiches Stück Release-Engineering.

Die Sprache, die den Laptop nie verließ

GeekBye hat seit September 2025 eine Einstellung für die Transkriptsprache. Sie funktionierte — lokal. Wähle Spanisch, und die On-Device-Speech-to-Text-Pipeline transkribierte brav Spanisch. Aber grep die v1.7.5-Codebasis nach dieser Einstellung, und du findest sie an genau drei Stellen: im Audio-Handler, in der Settings-UI und im Settings-Hook. Nicht im API-Client. Nicht im Session-Tracker. Vier Monate lang war jeder Request, der die Maschine verließ, sprachblind: die Session-Datensätze im Backend hatten keine Ahnung, welche Sprache sie repräsentierten, und der KI-Chat bekam spanische Transkripte ohne den geringsten Hinweis darauf, dass sie spanisch waren.

v1.7.6 ist das Release, in dem die Einstellung ihre Reise beendete — zwei Commits, ein Tag. Der Start der Audio-Session trägt jetzt transcriptLanguage in seinem Payload, und der Stream-Chat-Request der KI bekam dasselbe Feld, durchgefädelt über einen kleinen Helper, der die Einstellung liest und bewusst undefined zurückgibt, wenn sie auto oder nicht gesetzt ist — sodass ältere Backends sauber degradieren, statt an einem Feld zu ersticken, das sie nicht kennen. Im Diff versteckt sich außerdem ein stiller Bonus-Fix: um die Sprache zu übergeben, musste der Session-Start hinter die Sprachauflösung wandern — was, so wie wir es lesen, auch einen Fehlerpfad schloss, in dem eine Session gestartet (und auf die Limits angerechnet) werden konnte und dann verwaiste, wenn die Sprachauflösung einen Moment später fehlschlug.

Die Lektion verallgemeinert sich: eine Einstellung ist nicht ausgeliefert, wenn sie eine UI und einen Effekt hat. Sie ist ausgeliefert, wenn sie jeden Konsumenten erreicht, der von ihr wissen sollte. Unsere blieb vier Monate lang an der Netzwerkgrenze stehen, und niemand bemerkte es, weil das lokale Verhalten — das sichtbare Verhalten — die ganze Zeit korrekt war. (Das war, fürs Protokoll, der grobe erste Anlauf der Sprachbehandlung; der KI beizubringen, tatsächlich in der Sprache der Konversation zu antworten, ist ein viel späteres Kapitel dieser Geschichte.)

Cmd+/ — ein Overlay, das nicht über deine Keybindings lügt

Das nutzersichtbare Feature von v1.8.0 ist ein Tastenkürzel-Overlay auf Cmd+/ — 193 Zeilen neue Komponente und eine Designentscheidung, die es zu stehlen lohnt: es rendert keinen hartkodierten Spickzettel. Es holt die Live-Shortcut-Konfiguration und rendert customKeys || defaultKeys, sodass ein Nutzer, der seine Tasten umgemappt hat, seine Tasten sieht. Ein Shortcuts-Overlay, das jemandem die Defaults zeigt, der sie geändert hat, ist keine Dokumentation; es ist Desinformation mit hübscher Typografie.

Der Rest sind kleine Korrektheits-Details: das Overlay positioniert sich links oder rechts der App-Karte, je nachdem, auf welcher Bildschirmseite Platz ist, und schließt sich bei Escape, bei erneutem Cmd+/ oder bei einem Klick außerhalb. Cmd+/ selbst tritt demselben remappbaren Preset-System bei wie jeder andere Shortcut — was zählt, denn Cmd+/ ist in den meisten Editoren „Kommentar umschalten", und ein Tool für Entwickler sollte keine Editor-Taste besetzen, die man nicht verschieben kann.

Das „Bridge Release"

Das interessante Engineering passierte in den Versionsnummern, die niemand zweimal anschauen würde. v1.8.0 migrierte außerdem die Releases des Projekts in eine neue GitHub-Organisation — an der Oberfläche Org-Aufräumarbeit, wäre da nicht eine Eigenschaft von Desktop-Auto-Update: die Feed-URL ist ins Binary einkompiliert. Jede v1.8.0-Installation fragt die Releases der neuen Organisation ab. Und jede Installation da draußen — alle auf v1.7.7 oder älter — fragt die alte ab, für immer, es sei denn, dort taucht etwas auf.

Das ist das Henne-Ei-Problem: veröffentliche dein nächstes Release nur im neuen Repo, und die gesamte bestehende Flotte sieht es nie. Sechzehn Minuten nach dem v1.8.0-Tag landete ein neues Flag im Release-Skript: --publish-owner, das umschreibt, wohin electron-builder die Artefakte nach dem Build hochlädt — ausdrücklich „ohne den kompilierten App-Code zu beeinflussen", wie es der Code-Kommentar formuliert. Das ist der ganze Trick, und es ist genau die richtige Naht: der ins Binary einkompilierte Feed und das Upload-Ziel der Artefakte sind zwei verschiedene Entscheidungen, und eine Migration braucht sie für ein Release entkoppelt. Baue v1.8.1 mit Blick auf den neuen Feed, lade es ins alte Repo hoch; alte Clients sehen das Update dort, installieren es und wachen auf, indem sie die neue Organisation abfragen. Die Commit-Message nennt das ein „Bridge Release", und das ist der richtige Name. v1.8.1 wurde zwei Stunden und zwanzig Minuten nach v1.8.0 getaggt. (Für die Entstehungsgeschichte, warum dieses Projekt Auto-Update mit einem an Furcht grenzenden Respekt behandelt, siehe das Auto-Update, das unsere App unkaputtbar machte.)

Und v1.7.7? Ein Commit. Der Versions-Bump selbst. Kein Fix, kein Revert, keine Erklärung in der Historie — unsere beste Lesart ist ein Publish, das neu laufen musste, und wir geben das lieber zu, als uns eine Geschichte auszudenken. Manchmal existiert eine Versionsnummer, weil Software zu veröffentlichen ein Prozess der echten Welt mit Schluckaufs der echten Welt ist, keine reine Funktion des Source-Trees. Und warum aus 1.7 überhaupt 1.8 wurde: kein Commit sagt es, aber die Feed-Migration ist die bedeutsame Kompatibilitätsgrenze — jedes 1.8.x-Binary schaut auf eine andere Organisation als jedes 1.7.x-Binary — und das verdient einen Minor-Bump mehr als jedes Feature.

Drei Dinge, die uns diese Woche lehrte

1. Verfolge eine Einstellung bis zu jedem Konsumenten. Die Sprachpräferenz war vier Monate lang „fertig", während das Backend blind blieb. Dass das lokale, sichtbare Verhalten korrekt war, ist genau das, was die Lücke überleben ließ — die Audit-Frage lautet „wer sollte diesen Wert noch kennen?", gestellt an jeder Grenze.
2. Rendere Live-Konfiguration, keine Dokumentation. Das Shortcuts-Overlay liest dieselbe Source of Truth wie das Shortcut-System. Alles andere driftet ab, sobald ein Nutzer zum ersten Mal etwas anpasst.
3. Eine Feed-Migration braucht ein Release, das in beiden Welten lebt. Neuer Feed im Binary, altes Repo für den Upload. Wenn dein Release-Tooling diese beiden Ziele nicht trennen kann, füge das Flag hinzu, bevor du es brauchst — unseres kam sechzehn Minuten, nachdem es gebraucht wurde, was nah genug dran ist, um zu zählen.

Für das vorige Kapitel der v1-Geschichte, die Login-Seite IST die Demo (v1.7.5); und für den ganzen Bogen, die Anatomie, Software bis zur Perfektion auszuliefern.