Immich ora pubblica release candidate. Ecco come funzionano

Immich ora pubblica release candidate. Ecco come funzionano

Per gran parte della sua storia, Immich ha avuto un solo tipo di rilascio. Una nuova versione compariva su GitHub, la gente la scaricava e le segnalazioni di bug arrivavano nei giorni successivi. Poi una patch correggeva i peggiori. Funziona. Significa anche che la prima ondata di utenti fa i test sulle proprie librerie reali, senza essersi offerta volontaria.

Dalla v3 le cose sono cambiate. Prima che esca un rilascio importante, Immich ora pubblica una o più release candidate. La v3.0 ne ha avute quattro a giugno, prima che la versione stabile arrivasse il 2 luglio. La v3.2 ne ha avute tre. La v3.3 ne ha avute tre in meno di una settimana, tra il 29 settembre e il 2 ottobre.

Cos’è una release candidate

Una release candidate, o RC, è una versione che gli sviluppatori ritengono pronta, ma che vogliono far vedere a più persone prima di dichiararla definitiva. Le funzionalità sono complete. Non se ne aggiungono di nuove. Durante la fase RC si fanno test e si correggono bug, nient’altro.

La riconosci dal numero di versione. v3.3.0-rc.0 è la prima candidata per la v3.3.0, v3.3.0-rc.1 la seconda, e così via. Segue il versionamento semantico, in cui tutto ciò che viene dopo il trattino indica una pre-release. Una pre-release conta sempre come più vecchia della versione a cui porta, quindi v3.3.0-rc.2 viene prima di v3.3.0. Quando nessuno trova niente di grave nell’ultima candidata, lo stesso codice esce come versione stabile.

Chi ha stampato in camera oscura conosce il meccanismo. Non esponi per primo il tuo foglio migliore. Fai un provino a strisce, lo controlli, correggi, e solo allora fai la stampa vera. Una RC è il provino.

Come provarne una, e cosa può andare storto

Per il server, punti la variabile IMMICH_VERSION nel tuo file .env sulla candidata, per esempio v3.3.0-rc.2, ed esegui docker compose pull && docker compose up -d. Esiste anche un tag v3-rc che si aggiorna e punta sempre alla candidata più recente. Per le app mobili, gli utenti Android possono installare l’APK dalle note di rilascio oppure unirsi alla beta su Google Play. Gli utenti iOS si uniscono tramite TestFlight. I link si trovano in ogni rilascio su GitHub, ed è lì che vanno segnalati i bug.

Ora il rovescio della medaglia, perché c’è. Ogni RC arriva con lo stesso avviso: non è una versione stabile e può contenere bug o modifiche incompatibili. Quell’avviso non è una formalità. Una nuova versione di solito esegue migrazioni del database all’avvio. Quelle migrazioni vanno solo in avanti. Immich non supporta il downgrade, quindi se una RC rompe qualcosa, non puoi tornare alla versione precedente e andare avanti. Ripristini da un backup, oppure aspetti la candidata successiva.

Quindi la regola è noiosa, ed è quella giusta. Fai un backup recente sia del database sia della tua cartella di upload prima di provare una RC. Meglio ancora, fai i test su una seconda istanza con una copia dei tuoi dati, non sulla libreria che la tua famiglia usa ogni giorno. Se non hai un backup da cui hai ripristinato di recente, il nostro articolo sulla regola di backup 3-2-1 è un buon punto di partenza.

Se hai una macchina di riserva e un po’ di tempo, provare le RC è una delle cose più utili che puoi fare per un progetto open source. Scrivere codice non è l’unico modo per contribuire. Una segnalazione di bug chiara su una RC risolve un problema per migliaia di persone prima ancora che lo vedano.

Cosa significa per gli utenti PixelUnion

Non cambia nulla nel modo in cui usi PixelUnion. Non installiamo release candidate sulla tua istanza. Aspettiamo la versione stabile e poi la distribuiamo per fasi, come abbiamo fatto con la v3. Ricevi le nuove funzionalità dopo che sono passate per la fase RC e per i nostri controlli.

Seguiamo però le RC da vicino. Ci dicono in anticipo cosa sta arrivando, così possiamo prepararci e parlartene. E dato che più persone fanno test prima del rilascio finale, le versioni stabili che arrivano a te dovrebbero riservare meno sorprese. È un bene per la comunità del self-hosting, ed è un bene per noi.

Vorremmo fare di più che stare a guardare. In futuro vogliamo offrire una versione beta di PixelUnion. Se ci dici che vuoi partecipare, la tua istanza riceverà le nuove versioni di Immich prima del rilascio stabile, così potrai aiutare a testarle e dare un feedback in fretta. Quel feedback torna al progetto Immich, ed è proprio questo lo scopo. Non sappiamo ancora se e quando arriverà questa funzione. Appena ne sapremo di più, lo leggerai qui per primo.

Se preferisci lasciare a qualcun altro test, backup e aggiornamenti, siamo qui per questo.

Inizia gratis con PixelUnion →

Foto di copertina di Francisco Gonzalez su Unsplash.