Il problema originale era reale nel modello dell’app ZimaOS del 2024–2025: installare un’app con latest poteva risolvere quel tag al momento dell’installazione, ma ZimaOS conservava poi la versione risolta invece di seguire automaticamente le future modifiche del registro associate allo stesso tag. Zima-Giorgio ha affermato che questo comportamento era intenzionale per garantire la stabilità e ha avvertito ripetutamente che forzare l’aggiornamento di un’app avrebbe potuto danneggiarla.
Da allora sono cambiate due cose. Innanzitutto, ZimaOS 1.7 ha introdotto App Store 2.0, con una pagina dedicata alla gestione delle app installate e allo stato degli aggiornamenti. In secondo luogo, la semantica di Docker rimane importante: un container in esecuzione non diventa automaticamente la nuova immagine solo perché il tag latest del registro è cambiato. Un aggiornamento richiede sempre il rilevamento e il download di un’immagine modificata, oltre alla ricreazione del container o dello stack.
Il design storico di ZimaOS risolveva il tag e poi fissava la versione
Giorgio ha spiegato che latest era effettivo quando l’app veniva installata, dopodiché ZimaOS manteneva stabile la versione. L’obiettivo era ridurre le interruzioni impreviste causate dalle modifiche alle immagini upstream senza che gli utenti ne fossero consapevoli.
Lo stesso problema della community si è poi presentato con develop e probabilmente con qualsiasi tag denominato modificabile, non solo latest.
In Docker, latest non significa mai “aggiorna automaticamente il mio container in esecuzione”
Un tag modificabile è solo un puntatore del registro. Se example/app:latest punta domani a una nuova immagine, un container già creato continua a usare l’immagine esistente finché un processo di aggiornamento non la scarica e non ricrea il container.
Pertanto, “latest” e “aggiornamento automatico” sono concetti distinti anche al di fuori di ZimaOS.
La fonte utilizzava tag di versione espliciti come soluzione alternativa
CogZog ha riferito di aver modificato manualmente il tag di Immich impostandolo sul numero di versione pubblicato, riuscendo così ad aggiornare l’app alla versione v1.132.3. In seguito, Giorgio ha dichiarato che gli utenti che necessitavano di una versione specifica potevano modificare il campo della versione dell’app e salvare.
Si trattava di una soluzione alternativa a livello di community/utente, non della prova che aggiornare ciecamente ogni app all’immagine upstream più recente fosse sicuro.
Le app con più container possono danneggiarsi se viene aggiornata una sola immagine
Immich è un buon esempio: i componenti server, machine learning, database e cache possono richiedere migrazioni coordinate. Modificare un solo tag senza seguire le istruzioni di rilascio e migrazione upstream dell’app può creare uno stack misto incompatibile.
ZimaOS 1.7 ha aggiunto una gestione esplicita degli aggiornamenti delle app installate
L’attuale App Store di ZimaOS presenta le app installate in un’unica pagina di gestione, includendo il relativo stato e la disponibilità di aggiornamenti. I pacchetti App Store 2.0 includono inoltre metadati della versione e hash dei contenuti utilizzati per rilevare le modifiche ai pacchetti.
Consulta l’attuale esperienza di aggiornamento dell’App Store.
Le app dello store e i Compose personalizzati hanno responsabili diversi per gli aggiornamenti
Per un pacchetto dell’App Store, il responsabile dello store decide quando pubblicare un aggiornamento del pacchetto sottoposto a test. Per uno stack Compose personalizzato, il responsabile sei tu: decidi il tag o il digest dell’immagine, leggi le note di rilascio upstream, scarichi la nuova immagine e ricrei lo stack.
Non aspettarti che lo store riscriva un file Compose personalizzato o esegua automaticamente la migrazione di un database personalizzato.
Fissare esplicitamente la versione è spesso più sicuro per i servizi importanti
Per database, gestori di foto, sistemi di automazione e altre app con stato, un tag o digest di versione testato, insieme a una finestra di aggiornamento pianificata, consente di preparare un ripristino e di avere il tempo di leggere le modifiche incompatibili.
Per strumenti usa e getta o senza stato, seguire un tag modificabile può essere accettabile, purché sia comunque tu a controllare quando eseguire il download e la ricreazione.
Domande frequenti sugli aggiornamenti dei tag Docker
L’utente della fonte aveva frainteso completamente latest di Docker?
No. Nel design storico ZimaOS fissava effettivamente la versione dell’app risolta, ma Docker richiede anche di scaricare l’immagine e ricreare il container per aggiornare un container in esecuzione.
L’attuale ZimaOS dispone di una pagina per la gestione degli aggiornamenti delle app?
Sì. App Store 2.0 ha aggiunto lo stato e la gestione degli aggiornamenti delle app installate.
Ogni app dovrebbe sempre seguire automaticamente latest?
No. Gli aggiornamenti tramite tag modificabili possono introdurre modifiche incompatibili, soprattutto nelle applicazioni con stato o composte da più container.
