ich lese hier immer wieder (und es ist mir auch schon selber passiert), dass nach längerer Zeit vom Anwender ein Update von FHEM durchgeführt wird und ganz zufällig ein Modul genau einen Tag vorher vom Entwickler aktualisiert wurde, welches nun einen neuen noch unbekannten Fehler aufweist. Nach einem Tag laufen dann auch die Meldungen dazu im Forum auf und in der Regel werden die Fehler schnell behoben.
Um den Ärger für die Anwender zu reduzieren könnte man doch zwei Update-Zweige machen: Einen der alles auf den aktuellsten Update-Stand bringt und einen der nur die Module aktualisiert die älter als z.B. 5 Tage sind. Damit wären die potentiellen Auswirkung eines Fehlers reduziert auf einen kleineren Kreis von Mutigen.
Für Sicherheitsrelevante Updates könnte man ja Ausnahmen definieren, damit diese bei Bedarf sofort durchschlagen.
Interessant
schaue mal mit was die Gemeinde so meint.
Ich persönlich finde diese Idee echt gut.
LG
Tom
mal unabhängig von dem unbekannten
Zitatkönnte man
der dann die arbeit hat...
das wird nicht wirklich helfen sondern verschiebt das problem zum größten teil nur um 5 tage weil dann alle später den update bekommen.
also... "könnte man" bedeutet: kann ich leider nicht weil ich kein Entwickler bin und ich weiß auch nicht wer das genau macht. Es geht ja nicht um ein spezielles Modul sondern um die Hauptstruktur:-)
Ich denke nicht, dass sich das Problem verschiebt. Es gibt hier sehr viele Anwender mit sehr unterschiedlichen Fähigkeits-Graden. Die mit höheren Fähigkeiten würden es auf Wunsch weiterhin direkt bekommen und die anderen (die sich schwer tun den Fehler überhaupt erst mal zu finden und das Modul temporär auf alten Stand zurückzuwechseln) werden verschont. Update-Wellen sind ja nicht wirklich neu (Windows, Android, usw.)
Zitat von: StephanFHEM am 02 März 2019, 14:12:54
also... "könnte man" bedeutet: kann ich leider nicht weil ich kein Entwickler bin und ich weiß auch nicht wer das genau macht. Es geht ja nicht um ein spezielles Modul sondern um die Hauptstruktur:-)
Ich denke nicht, dass sich das Problem verschiebt. Es gibt hier sehr viele Anwender mit sehr unterschiedlichen Fähigkeits-Graden. Die mit höheren Fähigkeiten würden es auf Wunsch weiterhin direkt bekommen und die anderen (die sich schwer tun den Fehler überhaupt erst mal zu finden und das Modul temporär auf alten Stand zurückzuwechseln) werden verschont. Update-Wellen sind ja nicht wirklich neu (Windows, Android, usw.)
svn trunk ist eben der dev-zweig.
Ich bin der Meinung von justme1968
Gesendet von meinem SM-J510FN mit Tapatalk
FHEM ist kein Kopflossystem. Wer FHEM verwenden möchte der sollte sich im klaren sein das er ein klein wenig Zeit investieren muß. Und somit sollte es kein Problem sein am Abend ins Forum zu gehen und kurz mal über die Themen zu blicken. Dann sein Update machen und gut ist.
Also ich finde es schon interessant - nicht jedes System muss vom update her "bleeding Edge" sein, und wenn Teile der FHEM User weiter auf dem aktuellen update bleiben und Bugs finden ist es toll - die 5 Tage alte Version hätte dann zumindest einen "Filter"
Zitat von: StephanFHEM am 02 März 2019, 12:49:20
Um den Ärger für die Anwender zu reduzieren könnte man doch zwei Update-Zweige machen: Einen der alles auf den aktuellsten Update-Stand bringt und einen der nur die Module aktualisiert die älter als z.B. 5 Tage sind. Damit wären die potentiellen Auswirkung eines Fehlers reduziert auf einen kleineren Kreis von Mutigen.
Für Sicherheitsrelevante Updates könnte man ja Ausnahmen definieren, damit diese bei Bedarf sofort durchschlagen.
Ich mache das für mich schon mit einem Fork des FHEM-Mirrors in ein Git-Repo in das ich manuell pull requests holen muss. Ich hole meine
controls_fhem.txt dann von dort (ist in der
controls.txt hinterlegt) und nicht mehr von fhem.de. Evaluiere gerade ob ich die Sachen erst in einen "testing"-Branch pulle bevor ich sie dann von testing in stable hole (und von dort aus dann ins System).
Was hier gewünscht wird, war jahrelang konzeptionell in FHEM vorhanden (es sollte einen stable-Zweig und einen development-Zweig geben) hat sich in der Praxis aber als unwirksam und verwaltungsaufwändig herausgestellt und wurde deshalb aufgegeben.
Könnte man das nicht einfach über ein Attribut in globals lösen analog zu den einstellbaren Ausnahmen welche Mods nicht geupdated werden sollen? ,,UpdateOlder 2" updated nur die Module wo die Änderung älter als zwei Tage ist. Ich weiß aber nicht, ob das Datum der Modul-Änderung ausgelesen werden kann. Dann hätte man keinen Verwaltungsaufwand weil alles Client-seitig selektiert werden würde.
so einfach ist das nicht ...
z.b. modul a hängt von b ab. a wird aktualisiert. jemand bemerkt einen problem das in b repariert werden muss. b wird einen tag später geändert. nach zwei tagen ist nur a im update und b immer noch falsch weil es erst noch einen tag später kommt.
einfach x tage verzögern ohne abhängigkeiten zu berücksichtigen reicht nicht. alles was eventuell gehen könnte verursacht aufwand deutlich mehr aufwand.
also wenn jemand die meinung auf noob-ebene lesen will - bitte:
in dem fall seh nicht mal ich eine user-verbesserung.
immerhin schafft mans sehr leicht, auf den stand vor dem update zu kommen - sei es über die (glücklicherweise vorhanden) zwangs-sicherung der veränderten dateien oder über seine eigenen backups.
ausserdem bezweifel ich, dass alle "mutigen" auch alle szenarien des problems abdecken und auch melden. je mehr ihre fehler melden, je mehr kann der modulautor wohl raus filtern, wo das problem liegt :P
da wärs vielleicht lustiger, nen knopf einzubauen, der dann die sicherungen zurück spielt, ohne dass der geneigte noob telnet, winscp, grafische oberflächen oder was weiß ich alles anwerfen muß (nur ein gedankenblitz, keine bitte und auch kein bedarf von meiner seite).