Hallo @damalgos!
Ich hatte deine Nachricht nicht gesehen, aber jetzt antworte ich dir 
Ich gebe dir meine Meinung dazu. Grundsätzlich könnte es zwar nett klingen, aber in der Praxis denke ich, dass es ein Rückschritt zur Version 3 und ihren Problemen wäre, gerade dort, wo wir in der Version 4 einen sauberen Prozess eingeführt haben, der die Integrität und Stabilität der Software garantiert.
Ich erkläre es dir: Wenn wir ein Docker-Image von Gladys 4 deployen, deployen wir einen « atomaren » Build, also eine eingefrorene Version, die getestet, gebaut und deployed wurde.
Dieser Build hat eine Versionsnummer, einen Hash, es ist ein kohärenter Satz, der getestet wurde, und du bist dir sicher (dank des Build-Hashes), dass du, wenn du die neue Version der Software herunterlädst, den richtigen Build einer bestimmten Versionsnummer erhalten hast. (Und nicht eine gefälschte Version oder eine fehlerhafte Datei im Falle eines Netzwerkfehlers)
Wenn Watchtower Gladys aktualisiert, hast du die absolute Garantie, dass das Update entweder erfolgreich ist oder scheitert (und du somit in der vorherigen Version bleibst, aber nicht in einem halbfertigen Zustand).
Im Falle eines Netzwerkproblems ist es physikalisch unmöglich, dass du in einem Zwischenzustand landest, in dem du die Hälfte der Dateien der vorherigen Version und die Hälfte der Dateien der nächsten Version hast.
Versuchen, diesen Prozess für bestimmte Dateien zu umgehen (mit einem Update über Github, wie du sagst), bedeutet, dass wir die ganze Arbeit machen müssen, die Docker erledigt (Überprüfung der Hashes usw.), und vor allem verlieren wir die Atomarität der Versionen und Updates
Die Atomarität zu verlieren, bedeutet, sich « mystischen » Fehlern auszusetzen, die schwer zu lösen sind, weil eine Versionsnummer nicht mehr einen bestimmten Satz von Dateien und eine kohärente Version bestimmt.
Wenn ein Benutzer mit einem Problem zu uns kommt, wenn er uns seine Gladys-Version sagt, hilft uns das nicht unbedingt: Wir müssen auch wissen, wann er die Dateien gezogen hat, das ist nicht ideal.
Ich weiß nicht, ob du die Idee verstehst? 
Rückkehr zum ursprünglichen Problem
Also, wenn ich dich richtig verstehe, bist du mit der Häufigkeit der Gladys-Releases nicht zufrieden? ^^
An sich ist das Erstellen einer neuen Version von Gladys ein Klick auf einen Knopf, nichts weiter (das dauert 10 Sekunden).
Wenn du den Release-Plan ansiehst, mache ich normalerweise alle zwei Wochen ein Release (außer im Sommer, da alle im Urlaub waren, also vermeide ich ein Release, das potenziell Auswirkungen auf die Installation der Leute haben könnte, während sie nicht zu Hause sind. Und wenn deine Hausautomation gerade dann ausfällt, wenn du dein Zuhause überwachen möchtest, ist das nicht ideal).
Wenn wir zu einem intensiveren Rhythmus übergehen, verlieren wir an Release-Qualität, ich habe bereits nicht viele Rückmeldungen zu den Dev-Builds, die ich mache, wenn wir auf wöchentlich oder alle vier Tage gehen, bin ich mir nicht sicher, ob die Community mitzieht, und vor allem ist es nicht wirklich im Einklang mit den Werten der v4: Wir machen die Dinge richtig, Stabilität ist wichtiger als Schnelligkeit.
Zum Zigbee2mqtt
Da deine Frustration vom Zigbee2mqtt kommt, wäre eine Lösung, es anders für das Zigbee2mqtt zu machen:
- Eine automatische Erkennung der Feature-Typ/Kategorie einrichten, wie wir es z.B. für Philips Hue gemacht haben?
- Dem Benutzer ermöglichen, bestimmte nicht erkannte Geräte selbst in der UI zu deklarieren?
Was denkst du darüber?
