Salut @damalgos !
J’avais pas vu ton message, je rebondis maintenant 
Je te dis mon avis là dessus, dans l’idée ça pourrait sembler sympa, mais en pratique je pense que ce serait un retour en arrière à la v3 et ses travers, là ou justement dans la v4 on a introduit un process propre qui garanti l’intégrité et la stabilité du logiciel.
Je m’explique: quand on déploie une image Docker de Gladys 4, on déploie un build “atomique”, c’est à dire une version figée qui a été testée, buildée, et déployée.
Ce build il a un numéro de version, un hash, c’est un ensemble cohérent qui a été testé, et tu es certain (grâce au hash du build), que lorsque tu récupère la nouvelle version du logiciel, tu as reçu le bon build d’un numéro de version précis. (Et pas une version pirate, ou un fichier malformé en cas d’erreur réseau)
Quand Watchtower met à jour Gladys, tu as la garanti absolue que la mise à jour va soit réussir, soit échouer (et ainsi tu vas rester dans la version précédente, mais pas dans un état batard).
En cas de problème de réseau, c’est physiquement impossible que tu atterrisse dans un état intermediaire ou tu aurais la moitié des fichiers de la version d’avant, et la moitié des fichiers de la version d’après.
Essayer de bypasser ce process pour certains fichiers (avec une mise à jour via Github comme tu dis), c’est devoir faire nous même tout le travail que fait Docker (vérification des hash, etc…), et surtout c’est perdre l’atomicité des versions et des mises à jours
Perdre l’atomicité, c’est s’exposer à des bugs “mystiques” assez dur à résoudre, car un numéro de version ne détermine plus un set de fichiers données et cohérent.
Si un utilisateur vient nous voir avec un problème, si il nous dit son numéro de version Gladys, ça ne nous aidera pas forcément: on devra savoir aussi à quelle moment il a fait son pull des fichiers, c’est pas terrible.
Je sais pas si tu vois l’idée ? 
Retour au problème initial
Bon si je comprend bien, tu n’es pas satisfait de la fréquence des release Gladys ? ^^
En soit, faire une nouvelle version de Gladys, c’est un clic sur un bouton, rien de plus (ça prend 10 sec).
Si tu regarde le planning des releases, je fais en général une release toutes les 2 semaines (hors été, tout le monde était off donc j’évite de faire une release qui va potentiellement avoir un impact sur l’installation des gens pendant qu’ils sont hors de chez eux. Et si ta domotique casse au seul moment ou tu veux justement surveiller ton domicile, c’est pas top).
Si on décide de passer à un rythme plus soutenu, on va perdre en qualité de release, déjà que là actuellement j’ai déjà pas énormément de retour sur les builds dev que je fais, si on passe à toutes les semaines, ou tous les 4 jours, je suis pas certain que la communauté suive, et surtout ce n’est pas vraiment en accord avec les valeurs de la v4: on fait les choses bien, la stabilité est plus important qu’aller vite.
Pour parler du Zigbee2mqtt
Vu que ta frustration vient du Zigbee2mqtt, une solution serait de faire différemment pour le Zigbee2mqtt:
- Mettre en place une détection automatique des feature type/category comme on a fait pour le Philips Hue par exemple ?
- Permettre à l’utilisateur de déclarer lui même certain périphériques non reconnu dans l’UI ?
Tu en pense quoi ?
