Het oorspronkelijke probleem bestond echt in het appmodel van ZimaOS uit 2024–2025: bij het installeren van een app met latest kon die tag op het moment van installatie worden opgelost, maar ZimaOS behield vervolgens de opgeloste versie in plaats van automatisch toekomstige registerwijzigingen achter dezelfde tag te volgen. Zima-Giorgio zei dat dit gedrag bewust was gekozen voor stabiliteit en waarschuwde herhaaldelijk dat het forceren van een app-upgrade de app kon laten vastlopen.
Sindsdien zijn er twee dingen veranderd. Ten eerste introduceerde ZimaOS 1.7 App Store 2.0, met een speciale beheerpagina voor geïnstalleerde apps en een updatestatus. Ten tweede blijven de Docker-semantieken belangrijk: een actieve container wordt nooit automatisch de nieuwe image alleen omdat de tag latest van het register is gewijzigd. Voor een update moet altijd worden gedetecteerd dat er een gewijzigde image is, die image worden opgehaald en de container of stack opnieuw worden aangemaakt.
Het historische ontwerp van ZimaOS loste de tag op en zette daarna de versie vast
Giorgio legde uit dat latest effect had bij het installeren van de app, waarna ZimaOS de versie stabiel hield. Dit was bedoeld om onverwachte problemen te beperken die konden ontstaan doordat upstream-images onder gebruikers vandaan veranderden.
Hetzelfde probleem uit de community deed zich later voor met develop en waarschijnlijk met elke veranderlijke benoemde tag, niet alleen met latest.
Docker latest betekent nooit: ‘Werk mijn actieve container automatisch bij’
Een veranderlijke tag is slechts een verwijzing in een register. Als example/app:latest morgen naar een nieuwe image verwijst, blijft een al gemaakte container de bestaande image gebruiken totdat een updateproces die image ophaalt en de container opnieuw aanmaakt.
Daarom zijn ‘latest’ en ‘automatische update’ ook buiten ZimaOS twee afzonderlijke begrippen.
De bron gebruikte expliciete versietags als tijdelijke oplossing
CogZog meldde dat de tag van Immich handmatig was gewijzigd in het gepubliceerde versienummer, waarna de app naar v1.132.3 werd bijgewerkt. Giorgio zei later dat gebruikers die een specifieke versie nodig hadden, het app-versieveld konden bewerken en opslaan.
Dit was een tijdelijke oplossing op community- of gebruikersniveau en geen bewijs dat het veilig is om elke app blind bij te werken naar de nieuwste upstream-image.
Apps met meerdere containers kunnen defect raken wanneer slechts één image wordt bijgewerkt
Immich is een goed voorbeeld: de server-, machine-learning-, database- en cachecomponenten kunnen op elkaar afgestemde migratievereisten hebben. Eén tag wijzigen zonder de release- en migratie-instructies van de upstream-app te volgen, kan leiden tot een incompatibele gemengde stack.
ZimaOS 1.7 voegde expliciet beheer van updates voor geïnstalleerde apps toe
De huidige ZimaOS App Store toont geïnstalleerde apps op één beheerpagina, inclusief hun status en de beschikbaarheid van updates. Pakketten van App Store 2.0 bevatten ook versiegegevens en inhoudshashes die worden gebruikt om pakketwijzigingen te detecteren.
Bekijk de huidige update-ervaring van de App Store.
Voor App Store-apps en aangepaste Compose-apps zijn verschillende partijen verantwoordelijk voor updates
Bij een App Store-pakket bepaalt de beheerder van de store wanneer een getest pakket wordt gepubliceerd. Bij een aangepaste Compose-stack ben jij de beheerder: jij bepaalt de imagetag of -digest, leest de upstream-releaseopmerkingen, haalt de nieuwe image op en maakt de stack opnieuw aan.
Verwacht niet dat de store een aangepast Compose-bestand herschrijft of een aangepaste database automatisch migreert.
Expliciete versiepinning is vaak veiliger voor belangrijke services
Voor databases, fotobeheerders, automatiseringssystemen en andere stateful apps bieden een geteste versietag of digest en een bewust gepland upgradevenster vaak een betere voorbereiding op terugdraaien en tijd om incompatibele wijzigingen te lezen.
Voor wegwerpbare of stateless tools kan het acceptabel zijn een veranderlijke tag te volgen, zolang je zelf bepaalt wanneer het ophalen van de image en het opnieuw aanmaken plaatsvinden.
Veelgestelde vragen over Docker-tაგupdates
Heeft de gebruiker uit de bron Docker latest volledig verkeerd begrepen?
Nee. ZimaOS zette de opgeloste appversie in het historische ontwerp inderdaad vast, maar Docker zelf vereist ook dat een image wordt opgehaald en een actieve container opnieuw wordt aangemaakt.
Heeft het huidige ZimaOS een beheerpagina voor app-updates?
Ja. App Store 2.0 voegde een updatestatus en beheer voor geïnstalleerde apps toe.
Moet elke app altijd automatisch latest volgen?
Nee. Updates via veranderlijke tags kunnen incompatibele wijzigingen introduceren, vooral bij stateful apps of toepassingen met meerdere containers.
