Hallo 
Das Zigbee2Mqtt-Image wurde vor einigen Stunden aktualisiert und mein Watchtower hat seine Arbeit gut gemacht 
Leider hat Version 1.19.0 ein Problem (siehe hier: NPM crashes on Raspberry Pi 3 B+ in the latest Docker image · Issue #7662 · Koenkk/zigbee2mqtt · GitHub)
Sollte man die Nutzung der Images im Modus „latest“ einstellen? Aber wie aktualisiert man sie dann?
Oder sollte man das als ein seltenes Problem betrachten (das hoffentlich schnell behoben wird)?
Spezifische Version
Aber das bedeutet, dass man Updates testen und verwalten muss
Ich denke, das wird schnell behoben.
Ich weiß gerade nicht, wie ich die Updates verwalten soll. Dafür muss man ein System zur Neuerstellung/Aktualisierung von Containern verwalten und das ist nicht einfach.
Da kann man nicht viel machen. Das kommt vor
Man muss die Entwicklung bei z2m beobachten und kommunizieren.
Schau dir an, was wir in der MQTT-Integration gemacht haben! Wir haben die Version festgelegt und einen Mechanismus zur Aktualisierung implementiert. Beim Starten von Gladys prüfen wir die Version des Containers und aktualisieren ihn bei Bedarf
Es gibt kein stabiles Tag oder eine Hauptversion bei z2m
Ich sehe zwei Lösungen:
Wir lassen den Tag latest und müssen im Falle eines solchen Bugs kommunizieren.
Wir fixieren eine « genehmigte » Version im Dienst Zigbee2Mqtt, die bei jeder neuen Release von Gladys neu bewertet wird. Das bedeutet, dass wir die neueste verfügbare Version von z2m testen müssen und, wenn sie funktioniert, den Dienst Zigbee2Mqtt für die Erstellung des Containers beim Start von Gladys aktualisieren.
Ich stimme @lmilcent zu, wobei die 2 quasi unmöglich ist (uns fehlt allen die Zeit).
Ich bevorzuge eine stabile Version, auch wenn das bedeutet, etwas Zeit für das Testen der Bilder zu investieren und nicht am selben Tag von den neuesten Neuerungen zu profitieren.
Ich werde mir ansehen, was bei Mqtt gemacht wird.
Für die Validierung neuer Versionen kann das relativ schnell erledigt werden.
In maximal einer Woche ist das erledigt, und ohne sich zu sehr den Kopf zu zerbrechen, vermeidet man die gestern aufgetretenen Bugs mit einem Container, der nicht mehr startet.
Am Ende, egal ob man eine Major/Minor-Version oder eine Latest-Version verwendet, das Problem wäre dasselbe wie bei dem Bug, den wir neulich gesehen haben: Wenn die Leute von Zigbee2mqtt eine kaputte Version auf den Tag schieben, den wir verwenden (egal welchen), dann wird es bei uns kaputt gehen.
Im Gegensatz zu NPM garantiert ein Docker-Tag keine Unveränderlichkeit, man kann ein kaputtes Image auf einen bestehenden Tag schieben und damit das Bestehende kaputt machen.
Das ist das Problem bei Integrationen mit Third-Party-Anbietern, man ist völlig von ihnen abhängig, und man kann da nicht viel machen!
Ich bin mit der Idee einverstanden, aber in der Praxis werden wir nie die Geschwindigkeit ihres Projekts in Gladys erreichen, zumindest nicht derzeit, es gibt nicht genug Contributor/Volunteers, die an Gladys arbeiten, um häufige Reviews durchzuführen. Jedenfalls habe ich bei allen Dev-Builds, die ich mache, nie Tester.
Um ein Beispiel zu geben, im Fall von Z-Wave haben wir eine feste Version verwendet, um diese Probleme zu vermeiden, und die Version wird alle Jähr bestenfalls aktualisiert.