Gli aggiornamenti dell’App Store di ZimaOS non erano regolati da una semplice regola come «aggiornare sempre entro sette giorni dalla versione upstream». Nel thread della fonte del novembre 2025, Zima-Giorgio ha dichiarato che le versioni delle app erano gestite manualmente. Ha inoltre spiegato che le applicazioni di servizio potevano intenzionalmente rimanere indietro rispetto all’ultima versione upstream, perché la stabilità è importante, mentre i problemi che compromettono la disponibilità ricevono una priorità maggiore.
Le modifiche attuali dell’App Store 2.0 cambiano il modo in cui i cataloghi delle app vengono creati e distribuiti, ma non introducono magicamente una cadenza di manutenzione garantita. Il protocollo v2 supporta metadati sulla versione, timestamp degli aggiornamenti, note di rilascio, hash dei contenuti e aggiornamenti incrementali del client; tuttavia, qualcuno deve ancora mantenere e convalidare la definizione dell’app sorgente.
IceWhale ha dichiarato che le versioni dello Store erano gestite manualmente
La risposta diretta della fonte era breve: le versioni software dell’App Store erano gestite manualmente e gli store di terze parti o della community potevano fornire versioni più recenti.
Questo spiega perché la versione presente nel catalogo predefinito può differire dall’ultimo tag pubblicato dallo sviluppatore dell’applicazione upstream.
L’ultima versione non è sempre quella più sicura
Zima-Giorgio ha poi chiarito che non è sempre possibile garantire che le applicazioni di tipo servizio eseguano immediatamente l’ultima versione disponibile. La stabilità è uno dei fattori considerati.
Su un NAS, un aggiornamento affrettato del database o un passaggio a una versione principale può essere più problematico che utilizzare una versione convalidata, anche se precedente di una release rispetto a quella upstream.
I problemi che compromettono la disponibilità ricevono una priorità maggiore
IceWhale ha citato Immich come esempio: il pacchetto dell’App Store è stato aggiornato quando il server precedente ha smesso di essere compatibile con la corrispondente app mobile.
Si tratta di un utile principio di manutenzione: un malfunzionamento che impedisce l’uso normale può giustificare un intervento più rapido rispetto a una release upstream che introduce soltanto nuove funzionalità.
Le richieste pull fanno parte del flusso di manutenzione
IceWhale ha dichiarato che il team controlla regolarmente l’elenco delle richieste pull e le integra quando necessario. Giorgio ha incoraggiato gli utenti a inviare richieste pull o a creare i propri store e ha chiesto esplicitamente aiuto per aggiornare Uptime Kuma.
Questo rende l’App Store in parte collaborativo, anziché un catalogo chiuso gestito esclusivamente dal produttore.
L’attuale App Store v2 dispone di un protocollo di build e aggiornamento più esplicito
L’attuale documentazione per sviluppatori di IceWhale indica che lo store v2 generato include campi come:
-
version; -
update_at; -
release_note; -
content_hash.
I controlli degli aggiornamenti del client sono gestiti dall’indice dello store e dall’hash dei contenuti: le applicazioni invariate vengono saltate, mentre i metadati delle app o i file Compose modificati possono essere scaricati in modo incrementale.
Consulta l’attuale modello di build e aggiornamento dell’App Store v2.
I metadati della versione non creano uno SLA di manutenzione
Ora uno store può esporre informazioni migliori sulla versione e sugli aggiornamenti, ma il protocollo non stabilisce che ogni app debba essere aggiornata entro un numero fisso di giorni. La politica del catalogo e la convalida delle app restano processi gestiti da persone.
La versione dell’App Store e il tag dell’immagine Docker sono correlati, ma non identici
Un file Compose può fissare uno specifico tag dell’immagine, utilizzare un tag generico come latest oppure fare riferimento a uno stack composto da più servizi con diverse immagini indipendenti. La versione mostrata nello store può descrivere la definizione dell’app inclusa nel pacchetto, senza garantire che ogni immagine dello stack segua lo stesso numero di versione.
Quando la versione upstream esatta è importante, controlla la definizione Compose.
Gli aggiornamenti principali delle applicazioni richiedono maggiore cautela
Applicazioni come Nextcloud, Immich, i database e le piattaforme di domotica possono includere migrazioni dello schema o modifiche alla configurazione che causano incompatibilità. Un aggiornamento ritardato dell’App Store può essere intenzionale, mentre i manutentori verificano il comportamento delle migrazioni.
Esegui un backup dei dati dell’applicazione prima di passare manualmente a una versione più recente di quella presente nel catalogo.
Gli store della community possono essere più rapidi, ma comportano rischi diversi
Gli store di terze parti possono pubblicare prima versioni più recenti, ma la loro convalida, cadenza di aggiornamento e qualità dei rollback dipendono dai rispettivi manutentori. «Più recente dello store predefinito» non significa automaticamente «testata meglio».
Domande frequenti sugli aggiornamenti dell’App Store
IceWhale ha promesso un ciclo di aggiornamento mensile fisso?
No. La fonte afferma che le versioni erano gestite manualmente e che la stabilità e la disponibilità influivano sulla priorità.
Gli utenti possono contribuire all’aggiornamento delle app dell’App Store?
Sì. IceWhale ha incoraggiato esplicitamente l’invio di richieste pull e la creazione di store di terze parti.
L’App Store v2 migliora i metadati degli aggiornamenti?
Sì. L’output attuale della v2 supporta la versione, l’orario di aggiornamento, le note di rilascio e i controlli degli aggiornamenti basati sull’hash dei contenuti.
