Immich veröffentlicht jetzt Release Candidates. So funktionieren sie

Die meiste Zeit hatte Immich nur eine Art von Release. Eine neue Version erschien auf GitHub, die Leute zogen sie, und in den folgenden Tagen kamen die Bugmeldungen. Dann behob ein Patch-Release die schlimmsten davon. Das funktioniert. Es bedeutet aber auch, dass die erste Welle von Nutzern das Testen mit ihren echten Bibliotheken übernimmt, ohne sich dafür gemeldet zu haben.

Seit v3 ist das anders. Bevor ein großes Release erscheint, veröffentlicht Immich jetzt zuerst einen oder mehrere Release Candidates. v3.0 hatte im Juni vier davon, bevor die stabile Version am 2. Juli erschien. v3.2 durchlief drei. v3.3 hatte drei in weniger als einer Woche, zwischen dem 29. September und dem 2. Oktober.

Was ein Release Candidate ist

Ein Release Candidate, kurz RC, ist eine Version, die die Entwickler für fertig halten, auf die aber mehr Leute schauen sollen, bevor sie endgültig wird. Die Features sind fertig. Neue kommen nicht hinzu. In der RC-Phase wird getestet und werden Bugs behoben, sonst nichts.

Du erkennst einen RC an der Versionsnummer. v3.3.0-rc.0 ist der erste Kandidat für v3.3.0, v3.3.0-rc.1 der zweite und so weiter. Das folgt der semantischen Versionierung, bei der alles nach dem Bindestrich eine Vorabversion kennzeichnet. Eine Vorabversion gilt immer als älter als die Version, auf die sie hinführt, also wird v3.3.0-rc.2 vor v3.3.0 einsortiert. Findet niemand im letzten Kandidaten etwas Ernstes, geht derselbe Code als stabiles Release raus.

Wer in der Dunkelkammer fotografiert, kennt das Muster. Du belichtest nicht zuerst dein bestes Blatt Papier. Du machst einen Probestreifen, prüfst ihn, korrigierst und machst erst dann den echten Abzug. Ein RC ist der Probestreifen.

Wie du einen testest, und was schiefgehen kann

Für den Server setzt du die Variable IMMICH_VERSION in deiner .env-Datei auf den Kandidaten, zum Beispiel v3.3.0-rc.2, und führst docker compose pull && docker compose up -d aus. Es gibt auch einen fortlaufenden v3-rc-Tag, der immer auf den neuesten Kandidaten zeigt. Bei den mobilen Apps können Android-Nutzer die APK aus den Release Notes installieren oder an der Beta bei Google Play teilnehmen. iOS-Nutzer machen über TestFlight mit. Die Links stehen bei jedem Release auf GitHub, und dort solltest du auch Bugs melden.

Jetzt zum Haken, denn es gibt einen. Jeder RC kommt mit derselben Warnung: Er ist kein stabiles Release und kann Bugs oder Breaking Changes enthalten. Diese Warnung ist keine Formalität. Eine neue Version führt beim Start meist Datenbankmigrationen aus. Diese Migrationen laufen nur vorwärts. Immich unterstützt kein Downgrade. Wenn ein RC also etwas kaputt macht, kannst du nicht zur vorherigen Version zurückwechseln und weitermachen. Du stellst ein Backup wieder her, oder du wartest auf den nächsten Kandidaten.

Die Regel ist also langweilig, und sie ist die richtige. Mach ein frisches Backup der Datenbank und deines Upload-Ordners, bevor du einen RC ausprobierst. Noch besser: Teste auf einer zweiten Instanz mit einer Kopie deiner Daten, nicht auf der Bibliothek, die deine Familie jeden Tag nutzt. Wenn du kein Backup hast, aus dem du kürzlich wiederhergestellt hast, ist unser Beitrag über die 3-2-1-Backup-Regel ein guter Anfang.

Wenn du einen freien Rechner und etwas Zeit hast, gehört das Testen von RCs zu den nützlichsten Dingen, die du für ein Open-Source-Projekt tun kannst. Code schreiben ist nicht die einzige Art, etwas beizutragen. Eine klare Bugmeldung zu einem RC behebt ein Problem für Tausende von Menschen, bevor sie es je zu sehen bekommen.

Was das für PixelUnion-Nutzer bedeutet

An der Art, wie du PixelUnion nutzt, ändert sich nichts. Wir lassen keine Release Candidates auf deiner Instanz laufen. Wir warten auf das stabile Release und rollen es dann schrittweise aus, so wie bei v3. Du bekommst die neuen Features, sobald sie die RC-Phase und unsere eigenen Prüfungen durchlaufen haben.

Die RCs verfolgen wir trotzdem genau. Sie zeigen uns früh, was kommt, damit wir uns vorbereiten und dir davon erzählen können. Und weil vor dem finalen Release mehr Leute testen, sollten die stabilen Versionen, die bei dir ankommen, weniger Überraschungen enthalten. Das ist gut für die Self-Hosting-Community, und es ist gut für uns.

Wir möchten mehr tun als zuschauen. In Zukunft wollen wir eine Betaversion von PixelUnion betreiben. Wenn du uns sagst, dass du mitmachen möchtest, bekommt deine Instanz neue Immich-Versionen schon vor dem stabilen Release, damit du mittesten und schnell Feedback geben kannst. Dieses Feedback geht zurück an das Immich-Projekt, und genau darum geht es. Ob und wann diese Funktion kommt, steht noch nicht fest. Sobald wir mehr wissen, liest du es hier zuerst.

Wenn du das Testen, die Backups und die Upgrades lieber jemand anderem überlässt, sind wir genau dafür da.

Starte kostenlos mit PixelUnion →

Titelfoto von Francisco Gonzalez auf Unsplash.