UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[haus-automatisierung]

@ro75 sagte in Anregung Thema Updates:

Da ist es für mich schon wichtig ob ich mit allem unter 100MB bleiben muss um keine Probleme zu bekommen

Die Info gehört aber in die Dokumentation und nicht in ein Changelog. Manche installieren ja auch erst jetzt VIS und bekommen das Changelog der älteren Versionen nie zu sehen. Du wusstest ja vorher gar nichts von dem 100MB Limit, oder? :)

[Feuersturm]

@ro75 Als normaler Anwender, möchte mich doch um solche Limitierungen im ersten Schritt gar nicht kümmern, wenn sie nicht ausdrücklich in der Doku vom Adapter geanannt sind. Wenn es ein Problem gibt, wird ein issue eröffnet und der Entwickler kann es sich dann anschauen.

[Thomas Braun]

@ro75 sagte in Anregung Thema Updates:

Da ist es für mich schon wichtig ob ich mit allem unter 100MB bleiben muss um keine Probleme zu bekommen oder denen aus dem Weg zu gehen ODER ob ich mit dem Update einfach frei ohne "Besorgnis" weiter machen kann.

Und das ist genau die Situation die ich hier meinte:

Wenn es mich momentan nicht betrifft ist es mir egal, wenn künftige Probleme mich erst gar nicht betreffen werden ist es mir recht.

[Ro75]

@haus-automatisierung sagte in Anregung Thema Updates:

Die Info gehört aber in die Dokumentation und nicht in ein Changelog.

List du nach jedem Update die Dokumentation neu durch, ob sich da grundlegende Daten geändert haben?

Ro75.

[Feuersturm]

@ro75 Ich schaue dann rein, wenn ich Probleme habe oder ich Fragen zur Konfiguration habe ;-)

[Homoran]

@ro75 jetzt wird es aber akademisch!

wenn es um ein Update geht, kann ich verstehen dass man den change-log nachvollziehen will.

ob das in der Ausführlichkeit viele machen, und damit diese Info im admin zu finden sein sollte/mzss, halte ich für fraglich.

Da reicht es meiner Meinung nach dies auf GitHub zu finden

[Ro75]

@feuersturm Dann müssten aber auch alle Dokumentationen aktuell gehalten werden - aber das ist in den seltesten Fällen der Fall.

Ro75.

[haus-automatisierung]

@ro75 Wir kommen hier von einem Thema zum nächsten. Angenommen Du machst nur sehr selten Updates, dann wird der Sprung immer größer und es liegen immer mehr Versionen dazwischen. Der Admin und js-controller per cli zeigt aber nur die letzten (7?) an. Also das, was in den news steht. Auch da könnten also viele etwas verpassen.

Wenn es ein Minor-Versionssprung ist, gucke ich schon was die neuen Features sind, ja. Und mit einem diff auf GitHub sehe ich ja auch sofort Änderungen in der Doku. Aber das machen wohl die wenigsten so.

[Ro75]

@homoran sagte in Anregung Thema Updates:

@ro75 jetzt wird es aber akademisch!
wenn es um ein Update geht, kann ich verstehen dass man den change-log nachvollziehen will.
ob das in der Ausführlichkeit viele machen, und damit diese Info im admin zu finden sein sollte/mzss, halte ich für fraglich.
Da reicht es meiner Meinung nach dies auf GitHub zu finden

Du hast ja recht. Ich habe doch nie gesagt, dass ich überall alle Infos haben möchte. Von mir aus kann es im ioBroker doch kurz und knapp sein. Aber einer der vielleicht auch bissel mehr wissen nöchte, sollte nach Möglichkeit diese auch bekommen.

Beispiel mit den 100 auf 500MB. Der Zusammenhang warum und weshalb kenne ich jetzt. Damit ist dieser Punkt für mich erfüllt und für mich ist dieser Punkt sehr relevant und werde daher sehr schnell aktualisieren.

Aber diese Entscheidung kann man eben nur durch Infos treffen.

Ro75.

[apollon77]

Hi,

interessantes Thema. Ich habe das Gefühl (was das Thema nicht abwerten soll!) das @Ro75 zur Minderheit der User gehört die die Details wissen wollen und verstehen wollen. Die allermeisten updaten nur und genug klicken auch Hinweise zu Breaking changes weg ud wundern sich das es dann nicht geht. ;-) (nein, ich wikll nicht die Diskussion erweitern!)

Generell stimme ich zu das, wenn es sinnvoll ist, man mehr Details als Entwickler liefern kann. In vielen Fällen würde das aber mehr Infos verursachen, die dann wieder noch weniger User lesen. Oder man müsste wirklich Admin und GitHub News/Changelog getrennt erstellen was wieder viel Aufwand beim Entwickler verursacht. Auf Issues verlinken mag eine Idee zu sein, aber aus der Erfahrung liesst das erst recht wieder "keiner" weil sich auch da ja ggf Seitenlange Diskussionen mit Logfiles und Iterationen von Änderungen verbergen - aber es eine End-Zusammenfassung am Ende nie gibt.

Wenn ich als Entwickler Fehler behebe die berichtet wurden oder Sentry-Crashes abarbeite dann steht da ein "Prevent Crash cases" im changelog weil es so ist - auch wenn ich verstanden habe wann die Zustandegekommen sind bin ich der Meinung das es nicht zielführend ist das zu erklären weil teilweise sehr speziell.
Bei Adaptern wie Alexa2 oder Meross oder so wo es am Ende externe Systeme der Hersteller gibt versuche ich immer zu schreiben ob Änderungen aufgrund von Änderungen der Hersteller gemacht wurden oder ob es Feature sind die dazu kommen. Aber auch bin ich nicht des Mehrwerts eines "ins Detail gehen" sicher.

Das Ziel des "Stable" Repos ist es das man idealerweise Adapter updaten kann wie seine Windows oder App-Store software ... da liesst doch auch keiner Changelogs - soweit es die überhaupt sinnvoll gibt. Stable Updates waren vorher mindestens 2 Wochen in latest ... wer hier sicherstellen will ob es Fehler gibt schaut idealerweise ins GitHub. Aber die Erwartung ist das es simpel ist. Das gute bei ioBroker ist das man im Einzelfall sich nur die alte Version merken (oder aus Logfile ziehen muss) und wieder downgraden kann. Und das ist - von viel Feedback - das was, meiner Erfahrung nach, die meisten User wollen. Update und es geht.

Es gibt immer Sonderfälle - sei es "uralt Tablet Inkompatibilitäten in Vis" die unabsichtlich reinkommen weil kein Entwickler so ein altes Gerät hat und. Muss gemeldet werden und dann kann man entscheiden ob es gefixt wird oder halt so ist (Ja vor allem bei "Uralt Browsern" ist das immer eine Diskussion - kenn ich auch aus der Firma :-) )
Bei einem Adapter wie "zigbee" wegen Probleme in einzelnen Versionen komplett alles neue zu verteufeln ist auch der falsche Ansatz :-)

Also lange rede kurzer Sinn: Man kann das Thema gern mal mit ins nächste Entwicklermeeting nehmen um dort noch einmal die Entwickler zu bitten detaillierter zu sein und nicht zu knapp - wenn sinnvoll. Ich glaube aber das Du da eine Ausnahme bist (vllt neben mir selbst ... ich schaue in meinem Produktivsystem auch eher 3 mal hin bevor ich was aktualisiere).

Ingo