Versionen
Zuletzt aktualisiert: 2026-08-03
Relayium erscheint in drei Rhythmen, und diese Seite benennt alle drei ehrlich: Die Web-App wird laufend ausgeliefert, die Kommandozeilenwerkzeuge bekommen Nummern und Tags, und die nativen Apps sind Entwicklungs-Builds, die noch nicht öffentlich veröffentlicht sind.
Jede Version unten wurde automatisch aus dem main-Branch getaggt, und nur dann, wenn die Prüfungen auf genau diesem Commit grün waren. Die vollständigen Änderungen einer Version — jeder enthaltene Commit — sind auf GitHub einen Klick entfernt.
Alle veröffentlichten Versionen
Neueste zuerst. Jede Version verlinkt ihre vollständigen Änderungen und Downloads auf GitHub.
- v0.15.02026-08-03
- v0.14.02026-08-02
- v0.13.02026-08-01
- v0.12.02026-07-30
- v0.11.12026-07-28
- v0.11.02026-07-28
- v0.10.22026-07-23
- v0.10.12026-07-23
- v0.10.02026-07-23
- v0.9.02026-07-22
- v0.8.12026-07-22
- v0.8.02026-07-22
- v0.7.02026-07-13
- v0.6.02026-07-13
- v0.5.02026-07-13
- v0.4.02026-07-13
- v0.3.12026-07-13
- v0.3.02026-07-13
- v0.2.02026-07-08
- v0.1.22026-07-08
- v0.1.12026-07-08
- v0.1.02026-07-08
Was eine Versionsnummer abdeckt
Ein Versions-Tag veröffentlicht zwei Programme: die CLI relayium und relayium-node, den Relay- und Speicher-Node für alle, die selbst hosten. Beide werden aus demselben Quellbaum gebaut — eine Version entsteht deshalb nur, wenn sich dieser Baum geändert hat.
- Die Web-App hat keine Versionsnummer. Ausgeliefert wird aus dem main-Branch, sobald ihre Prüfungen grün sind — was du im Browser benutzt, ist also meist neuer als die neueste Version in dieser Liste.
- Die macOS- und die iOS-App sind Entwicklungs-Builds, keine öffentlichen Releases. Keine der Versionen unten enthält sie.
- Ein Node folgt dieser Liste nicht von selbst: Er fragt den Server, zu dem er gehört, welche Version er ausführen soll. Eine neue Version ändert also nichts, bis jemand einen Rollout startet. Die CLI aktualisierst du mit relayium update.
Wie eine Veröffentlichung entsteht
Veröffentlicht wird nach Plan, nicht aus Erinnerung. Einmal pro Woche sieht ein Workflow nach, was seit der letzten Version dazugekommen ist, und hört in zwei Fällen ohne Tag auf: wenn sich am Code, der tatsächlich veröffentlicht wird, nichts geändert hat, und wenn die Prüfungen auf diesem Commit nicht grün sind.
- Beides ist von Grund auf so gewollt. Auf Erinnerung zu bauen hat schon einmal dazu geführt, dass ein fertiges Feature monatelang unveröffentlicht lag; und einen ungeprüften Commit zu taggen würde genau den Ausfall ausliefern, den der Plan verhindern soll.
- Wochen, in denen sich nur Dokumentation oder die Apps ändern, ergeben keine Version — die veröffentlichten Programme wären Byte für Byte die vorherigen.
Prüfen, was du heruntergeladen hast
Jede Veröffentlichung legt neben die Archive eine Prüfsummendatei und eine Signatur über diese Datei. Der Updater prüft beides, bevor er irgendetwas installiert, gegen einen ins Programm einkompilierten öffentlichen Schlüssel — ein manipuliertes Archiv scheitert damit auf deinem Rechner und hängt nicht daran, ob wir es auf unserem bemerkt haben.
- Für Netzwerke, die GitHub nicht erreichen, spiegelt Relayium seine eigenen Release-Dateien. Woher die Bytes kommen, ist eine Frage der Erreichbarkeit und keine des Vertrauens: Die Prüfung ist auf beiden Wegen dieselbe.
- Der Quellcode ist offen. Server, Node und Web-App stehen unter AGPL-3.0, die nativen Apps unter Apache-2.0 und die Dokumentation unter CC BY 4.0.