Les mises à jour de l’App Store de ZimaOS n’étaient pas régies par une règle simple telle que « toujours mettre à jour dans les sept jours suivant la publication en amont ». Dans le fil de discussion source de novembre 2025, Zima-Giorgio a indiqué que les versions des applications étaient maintenues manuellement. Il a également expliqué que les applications de service pouvaient intentionnellement rester en retard sur la dernière version publiée en amont, car la stabilité est importante, tandis que les problèmes empêchant le fonctionnement reçoivent une priorité plus élevée.
L’App Store 2.0 actuel modifie la manière dont les catalogues d’applications sont créés et distribués, mais il ne crée pas automatiquement une cadence de maintenance garantie. Le protocole v2 prend en charge les métadonnées de version, les horodatages de mise à jour, les notes de version, les hachages de contenu et les mises à jour incrémentielles côté client ; des personnes doivent toujours maintenir et valider la définition source de l’application.
IceWhale a indiqué que les versions du Store étaient maintenues manuellement
La réponse de la source était concise : les versions des logiciels de l’App Store étaient maintenues manuellement, et les magasins tiers ou communautaires pouvaient proposer des versions plus récentes.
Cela explique pourquoi la version du catalogue par défaut peut différer de la dernière balise publiée par le développeur de l’application en amont.
La dernière version n’est pas toujours la plus sûre
Zima-Giorgio a ensuite précisé qu’il n’était pas toujours possible de garantir que les applications de type service exécutent immédiatement la dernière version. La stabilité fait partie des critères de décision.
Pour un NAS, une mise à niveau précipitée d’une base de données ou vers une version majeure peut être plus perturbatrice que l’utilisation d’une version validée située une version en retrait par rapport à la version en amont.
Les problèmes empêchant le fonctionnement reçoivent une priorité plus élevée
IceWhale a cité Immich comme exemple : le paquet de l’App Store a été mis à jour lorsque l’ancien serveur n’était plus compatible avec l’application mobile correspondante.
Il s’agit d’un principe de maintenance utile : un problème qui empêche l’utilisation normale peut justifier une intervention plus rapide qu’une version en amont apportant uniquement de nouvelles fonctionnalités.
Les demandes de fusion font partie du processus de maintenance
IceWhale a indiqué que l’équipe vérifiait régulièrement la liste des demandes de fusion et les intégrait lorsque nécessaire. Giorgio a encouragé les utilisateurs à soumettre des demandes de fusion ou à créer leurs propres magasins, et a spécifiquement demandé de l’aide pour mettre à jour Uptime Kuma.
L’App Store est donc en partie collaboratif, plutôt qu’un catalogue fermé réservé au fournisseur.
L’App Store v2 actuel dispose d’un protocole de compilation et de mise à jour plus explicite
La documentation actuelle destinée aux développeurs d’IceWhale indique que le magasin v2 généré comprend des champs tels que :
-
version; -
update_at; -
release_note; -
content_hash.
Les vérifications de mise à jour côté client s’appuient sur l’index du magasin et le hachage de contenu. Les applications inchangées sont donc ignorées, tandis que les métadonnées ou les fichiers Compose modifiés peuvent être récupérés de manière incrémentielle.
Consultez le modèle actuel de compilation et de mise à jour de l’App Store v2.
Les métadonnées de version ne créent pas de SLA de maintenance
Un magasin peut désormais fournir de meilleures informations sur les versions et les mises à jour, mais le protocole n’impose pas que chaque application soit mise à jour dans un délai fixe. La politique du catalogue et la validation des applications restent des processus humains.
La version de l’App Store et la balise d’image Docker sont liées, mais pas identiques
Un fichier Compose peut verrouiller une balise d’image spécifique, utiliser une balise générale telle que latest ou faire référence à une pile composée de plusieurs services avec plusieurs images indépendantes. La version affichée par le magasin peut décrire la définition de l’application empaquetée, sans garantir que chaque image de la pile suit le même numéro de version.
Examinez la définition Compose lorsque la version exacte publiée en amont est importante.
Les mises à jour majeures d’applications exigent une prudence supplémentaire
Des applications telles que Nextcloud, Immich, les bases de données et les plateformes domotiques peuvent comporter des migrations de schéma ou des modifications de configuration incompatibles. Une mise à jour retardée de l’App Store peut être intentionnelle, le temps que les mainteneurs valident le comportement des migrations.
Sauvegardez les données de l’application avant de passer manuellement à une version plus récente que celle du catalogue.
Les magasins communautaires peuvent aller plus vite, avec un risque différent
Les magasins tiers peuvent publier plus rapidement des versions récentes, mais leur validation, leur cadence de mise à jour et la qualité de leurs mécanismes de restauration dépendent de leurs mainteneurs. « Plus récent que le magasin par défaut » ne signifie pas automatiquement « mieux testé ».
FAQ sur les mises à jour de l’App Store
IceWhale a-t-il promis un cycle de mise à jour mensuel fixe ?
Non. La source indique que les versions étaient maintenues manuellement et que la stabilité ainsi que la disponibilité influençaient les priorités.
Les utilisateurs peuvent-ils contribuer à la mise à jour des applications de l’App Store ?
Oui. IceWhale a explicitement encouragé les demandes de fusion et les magasins tiers.
L’App Store v2 améliore-t-il les métadonnées de mise à jour ?
Oui. La sortie v2 actuelle prend en charge la version, l’heure de mise à jour, les notes de version et les vérifications de mise à jour fondées sur le hachage de contenu.
