El problema original era real en el modelo de aplicaciones de ZimaOS de 2024–2025: instalar una aplicación con latest podía resolver esa etiqueta en el momento de la instalación, pero ZimaOS conservaba la versión resuelta en lugar de seguir automáticamente los futuros cambios del registro detrás de la misma etiqueta. Zima-Giorgio explicó que este comportamiento era intencionado por motivos de estabilidad y advirtió repetidamente que forzar la actualización de una aplicación podía romperla.
Desde entonces han cambiado dos cosas. Primero, ZimaOS 1.7 introdujo App Store 2.0, con una página específica para gestionar las aplicaciones instaladas y consultar su estado de actualización. Segundo, la semántica de Docker sigue siendo importante: un contenedor en ejecución nunca se convierte automáticamente en la nueva imagen solo porque la etiqueta latest del registro haya cambiado. Una actualización siempre requiere detectar o descargar una imagen modificada y volver a crear el contenedor o la pila.
El diseño histórico de ZimaOS resolvía la etiqueta y luego fijaba la versión
Giorgio explicó que latest era efectiva cuando se instalaba la aplicación, después de lo cual ZimaOS mantenía estable la versión. Esto pretendía reducir las interrupciones inesperadas causadas por cambios en las imágenes ascendentes sin que los usuarios lo supieran.
Más adelante, el mismo problema de la comunidad apareció con develop y probablemente con cualquier etiqueta con nombre mutable, no solo con latest.
En Docker, latest nunca significa «actualizar automáticamente mi contenedor en ejecución»
Una etiqueta mutable es solo un puntero del registro. Si example/app:latest apunta mañana a una imagen nueva, un contenedor ya creado seguirá utilizando su imagen actual hasta que un proceso de actualización descargue la nueva imagen y vuelva a crear el contenedor.
Por lo tanto, «latest» y «actualización automática» son conceptos distintos incluso fuera de ZimaOS.
La fuente utilizó etiquetas de versión explícitas como solución alternativa
CogZog informó que cambió manualmente la etiqueta de Immich por el número de versión publicada y consiguió actualizar la aplicación a v1.132.3. Más tarde, Giorgio dijo que los usuarios que necesitaran una versión específica podían editar el campo de versión de la aplicación y guardarlo.
Esto era una solución alternativa a nivel de la comunidad o del usuario, no una prueba de que actualizar ciegamente todas las aplicaciones a la imagen ascendente más reciente sea seguro.
Las aplicaciones con varios contenedores pueden fallar si solo se actualiza una imagen
Immich es un buen ejemplo: sus componentes de servidor, aprendizaje automático, base de datos y caché pueden requerir migraciones coordinadas. Editar una etiqueta sin seguir las instrucciones de publicación y migración del proyecto puede crear una pila mixta incompatible.
ZimaOS 1.7 añadió una gestión explícita de las actualizaciones de aplicaciones instaladas
La App Store actual de ZimaOS presenta las aplicaciones instaladas en una única página de gestión, incluido su estado y la disponibilidad de actualizaciones. Los paquetes de App Store 2.0 también incluyen metadatos de versión y hashes del contenido que se utilizan para detectar cambios en los paquetes.
Consulta la experiencia actual de actualización de la App Store.
Las aplicaciones de la tienda y las composiciones personalizadas tienen responsables de actualización distintos
En un paquete de la App Store, el responsable del mantenimiento de la tienda decide cuándo publicar una actualización probada del paquete. En una pila de Compose personalizada, tú eres el responsable: decides la etiqueta o el resumen de la imagen, lees las notas de la versión, descargas la nueva imagen y vuelves a crear la pila.
No esperes que la tienda reescriba un archivo de Compose personalizado ni migre automáticamente una base de datos personalizada.
Fijar explícitamente la versión suele ser más seguro para los servicios importantes
En bases de datos, gestores de fotos, sistemas de automatización y otras aplicaciones con estado, utilizar una etiqueta o un resumen de versión probado, junto con una ventana de actualización planificada, permite preparar una reversión y disponer de tiempo para leer los cambios incompatibles.
En herramientas desechables o sin estado, seguir una etiqueta mutable puede ser aceptable si aun así controlas cuándo se descarga la imagen y se vuelve a crear el contenedor.
Preguntas frecuentes sobre la actualización de etiquetas de Docker
¿El usuario de la fuente entendió completamente mal latest en Docker?
No. En el diseño histórico, ZimaOS realmente fijaba la versión resuelta de la aplicación, pero Docker también requiere descargar la imagen y volver a crear el contenedor para actualizar uno que esté en ejecución.
¿La versión actual de ZimaOS tiene una página de gestión de actualizaciones de aplicaciones?
Sí. App Store 2.0 añadió el estado y la gestión de actualizaciones de las aplicaciones instaladas.
¿Todas las aplicaciones deberían seguir siempre latest automáticamente?
No. Las actualizaciones mediante etiquetas mutables pueden introducir cambios incompatibles, especialmente en aplicaciones con estado o con varios contenedores.
