Källproblemet var verkligt i ZimaOS appmodell från 2024–2025: när en app installerades med latest kunde den taggen lösas vid installationstillfället, men ZimaOS behöll sedan den upplösta versionen i stället för att automatiskt följa framtida registerändringar bakom samma tagg. Zima-Giorgio sade att detta beteende var avsiktligt för stabilitetens skull och varnade upprepade gånger för att en framtvingad appuppgradering kunde göra att appen slutade fungera.
Två saker har förändrats sedan dess. För det första introducerade ZimaOS 1.7 App Store 2.0 med en särskild hanteringssida för installerade appar och uppdateringsstatus. För det andra är Docker-semantiken fortfarande viktig: en körande container blir aldrig automatiskt den nya avbildningen bara för att registrets latest-tagg har flyttats. En uppdatering kräver alltid att en ändrad avbildning upptäcks och hämtas, och att containern eller stacken återskapas.
Den historiska ZimaOS-designen löste taggen och låste sedan versionen
Giorgio förklarade att latest gällde när appen installerades, varefter ZimaOS höll versionen stabil. Syftet var att minska risken för oväntade problem när uppströmsavbildningar ändrades under användarna.
Samma problem i communityn uppstod senare med develop och sannolikt med alla muterbara namngivna taggar – inte bara latest.
Docker latest betyder aldrig ”uppdatera min körande container automatiskt”
En muterbar tagg är bara en pekare i ett register. Om example/app:latest pekar på en ny avbildning i morgon fortsätter en redan skapad container att använda sin befintliga avbildning tills ett uppdateringsflöde hämtar och återskapar den.
Därför är ”latest” och ”automatisk uppdatering” separata begrepp även utanför ZimaOS.
Källan använde explicita versionstaggar som en tillfällig lösning
CogZog rapporterade att Immichs tagg ändrades manuellt till det publicerade versionsnumret och att appen då uppgraderades till v1.132.3. Giorgio sade senare att användare som behövde en specifik version kunde redigera appens versionsfält och spara.
Detta var en lösning på community- eller användarnivå, inte ett bevis på att det är säkert att blint uppdatera alla appar till den senaste uppströmsavbildningen.
Appar med flera containrar kan sluta fungera när bara en avbildning uppdateras
Immich är ett bra exempel: server-, maskininlärnings-, databas- och cachekomponenterna kan kräva samordnade migreringar. Om en tagg redigeras utan att appens uppströmsinstruktioner för lansering och migrering följs kan en inkompatibel blandad stack skapas.
ZimaOS 1.7 lade till uttrycklig hantering av uppdateringar för installerade appar
Den aktuella ZimaOS App Store visar installerade appar på en gemensam hanteringssida, inklusive deras status och tillgängliga uppdateringar. App Store 2.0-paket innehåller också versionsmetadata och innehållshashar som används för att upptäcka paketändringar.
Se den aktuella uppdateringsupplevelsen i App Store.
Store-appar och anpassade Compose-stackar har olika uppdateringsansvariga
För ett App Store-paket avgör butikens underhållare när en testad paketuppdatering publiceras. För en anpassad Compose-stack är du underhållaren: du väljer avbildningens tagg eller digest, läser uppströmsprojektets versionsinformation, hämtar den nya avbildningen och återskapar stacken.
Förvänta dig inte att butiken skriver om en anpassad Compose-fil eller automatiskt migrerar en anpassad databas.
Det är ofta säkrare att uttryckligen låsa viktiga tjänster till en version
För databaser, fotoappar, automatiseringssystem och andra tillståndsbevarande appar ger en testad versionstagg eller digest, tillsammans med ett planerat uppgraderingsfönster, möjlighet att planera återställning och tid att läsa om eventuella inkompatibla ändringar.
För verktyg som är förbrukningsbara eller tillståndslösa kan det vara acceptabelt att följa en muterbar tagg, så länge du fortfarande styr när hämtningen och återskapandet sker.
Vanliga frågor om uppdatering av Docker-taggar
Missförstod användaren i källan Docker latest helt?
Nej. ZimaOS låste verkligen den upplösta appversionen i den historiska designen, men Docker kräver också att en avbildning hämtas och att en körande container återskapas för att uppdateras.
Har den aktuella versionen av ZimaOS en sida för hantering av appuppdateringar?
Ja. App Store 2.0 lade till uppdateringsstatus och hantering för installerade appar.
Bör alla appar alltid följa latest automatiskt?
Nej. Uppdateringar via muterbara taggar kan införa inkompatibla ändringar, särskilt i tillståndsbevarande appar eller appar med flera containrar.
