O problema original existia efetivamente no modelo de aplicações do ZimaOS de 2024–2025: instalar uma aplicação com latest podia resolver essa etiqueta no momento da instalação, mas o ZimaOS mantinha depois a versão resolvida, em vez de seguir automaticamente futuras alterações do registo por detrás da mesma etiqueta. Zima-Giorgio afirmou que este comportamento era intencional, por motivos de estabilidade, e alertou repetidamente que forçar uma atualização de uma aplicação poderia fazê-la deixar de funcionar.
Desde então, duas coisas mudaram. Primeiro, o ZimaOS 1.7 introduziu a App Store 2.0, com uma página dedicada à gestão das aplicações instaladas e ao estado das atualizações. Segundo, a semântica do Docker continua a ser importante: um contentor em execução nunca se torna automaticamente a nova imagem apenas porque a etiqueta latest do registo mudou. Uma atualização exige sempre detetar e obter uma imagem alterada, além de recriar o contentor ou a pilha.
O design histórico do ZimaOS resolvia a etiqueta e fixava depois a versão
Giorgio explicou que latest era aplicado quando a aplicação era instalada, após o que o ZimaOS mantinha a versão estável. A intenção era reduzir falhas inesperadas causadas por imagens a montante que mudassem sem aviso para os utilizadores.
Mais tarde, o mesmo problema da comunidade surgiu com develop e, provavelmente, com qualquer etiqueta nomeada mutável — não apenas latest.
No Docker, latest nunca significa “atualizar automaticamente o meu contentor em execução”
Uma etiqueta mutável é apenas um apontador no registo. Se example/app:latest apontar amanhã para uma nova imagem, um contentor já criado continuará a utilizar a imagem existente até que um processo de atualização obtenha a nova imagem e recrie o contentor.
Por isso, “latest” e “atualização automática” são conceitos distintos, mesmo fora do ZimaOS.
A fonte utilizou etiquetas de versão explícitas como solução alternativa
CogZog relatou ter alterado manualmente a etiqueta do Immich para o número da versão publicada, conseguindo atualizar a aplicação para a v1.132.3. Mais tarde, Giorgio afirmou que os utilizadores que precisassem de uma versão específica podiam editar o campo da versão da aplicação e guardar.
Esta foi uma solução alternativa ao nível da comunidade/utilizador, não uma prova de que seja seguro atualizar cegamente todas as aplicações para a imagem a montante mais recente.
As aplicações com vários contentores podem deixar de funcionar quando apenas uma imagem é atualizada
O Immich é um bom exemplo: os componentes do servidor, da aprendizagem automática, da base de dados e da cache podem ter requisitos de migração coordenados. Editar uma etiqueta sem seguir as instruções de lançamento e migração da aplicação a montante pode criar uma pilha mista incompatível.
O ZimaOS 1.7 adicionou uma gestão explícita das atualizações das aplicações instaladas
A App Store atual do ZimaOS apresenta as aplicações instaladas numa única página de gestão, incluindo o respetivo estado e a disponibilidade de atualizações. Os pacotes da App Store 2.0 também incluem metadados de versão e hashes de conteúdo utilizados para detetar alterações nos pacotes.
Consulte a experiência atual de atualização da App Store.
As aplicações da loja e as composições personalizadas têm responsáveis diferentes pelas atualizações
No caso de um pacote da App Store, o responsável pela manutenção da loja decide quando é publicada uma atualização testada do pacote. No caso de uma pilha Compose personalizada, o responsável é você: decide a etiqueta ou o resumo da imagem, lê as notas de lançamento a montante, obtém a nova imagem e recria a pilha.
Não espere que a loja reescreva um ficheiro Compose personalizado ou migre automaticamente uma base de dados personalizada.
Fixar explicitamente a versão é frequentemente mais seguro para serviços importantes
Para bases de dados, gestores de fotografias, sistemas de automatização e outras aplicações com estado, uma etiqueta ou um resumo de versão testado, juntamente com uma janela de atualização planeada, permite preparar uma reversão e ter tempo para ler as alterações incompatíveis.
Para ferramentas descartáveis ou sem estado, seguir uma etiqueta mutável pode ser aceitável, desde que continue a controlar o momento em que a imagem é obtida e o contentor recriado.
Perguntas frequentes sobre a atualização de etiquetas do Docker
O utilizador da fonte interpretou completamente mal o latest do Docker?
Não. O ZimaOS fixava efetivamente a versão resolvida da aplicação no design histórico, mas o próprio Docker também exige obter a imagem e recriar o contentor para atualizar um contentor em execução.
O ZimaOS atual tem uma página de gestão das atualizações das aplicações?
Sim. A App Store 2.0 adicionou o estado e a gestão das atualizações das aplicações instaladas.
Todas as aplicações devem seguir sempre o latest automaticamente?
Não. As atualizações através de etiquetas mutáveis podem introduzir alterações incompatíveis, especialmente em aplicações com estado ou com vários contentores.
