FHEM Tutorial-Reihe - Warum es in FHEM keine Versionen gibt

Ich hatte vor kurzem eine Diskussion auf Facebook. Nachdem ich bemängelt hatte, dass es in FHEM keine Versionen gibt, wurde versucht das Gegenteil festzustellen. Weiterhin wurde behauptet, dass man mit einem “update all” »wissentlich den Bereich der Versionierung verlässt« (was natürlich Quatsch ist). Da in diese Diskussion viel Zeit von meiner Seite investiert wurde, möchte ich die Ergebnisse hier noch einmal für alle festhalten, damit die Zeit nicht komplett verschwendet ist - denn mein Gegenüber besteht nach wie vor auf die Existenz von Versionen in FHEM. Aber von Anfang an.

Wenn man FHEM neuinstallieren möchte, kann man fertig gestrickte Pakete nutzen. Diese liegen in unterschiedlichen Formaten vor und sind (Stand Anfang 2021) wie folgt benannt:

Last released version: (as of 2020-01-26): fhem-6.0.tar.gz, fhem-6.0.zip, fhem-6.0.deb

Jetzt könnte man davon ausgehen, dass 6.0 die Versionsnummer von diesem Release darstellt. Und genau dort möchte ich einsteigen. Dafür müssen wir aber zuerst feststellen, wie FHEM entwickelt und aktualisiert wird. Der Prozess läuft wie folgt ab:

In der Versionsverwaltung (SVN) werden ständig Änderungen von hunderten Entwicklern hinzugefügt (commit). Es gibt nur einen Entwicklungszweig (branch), in welchem von allen gearbeitet wird. So spart man sich das in SVN sehr umständlich gelöste zusammenfügen (merge) von Entwicklungszweigen. Jede Änderung kommt also immer nur “oben drauf”. Man erhält also eine lange Liste von einzelnen Änderungen, welche aufeinander aufbauen. Einzelne Änderungen (commits) aus der Vergangenheit zu entfernen ist also nicht möglich - nur durch eine weitere Änderung, welche wieder “oben drauf” kommt. Ich hoffe das Prinzip ist verständlich. Ansonsten hilft Wikipedia.

Nun veröffentlichen die FHEM-Entwickler für die Kernkomponente immer mal wieder Änderungen, welche ältere Systeme bei einem update eventuell beeinträchtigen könnten bzw. die Funktionsweise ändern. Um dies zu vermeiden, wurde das sogenannte featureLevel eingeführt. Dieses ist eine innerhalb von FHEM frei konfigurierbare Information (über ein Attribut), welche im Code abgefragt wird und je nach Konfiguration somit das Verhalten des Systems in manchen Bereichen verändert.

Aber was bedeutet nun die ominöse Zahl 6.0 im Dateinamen der Installationspakete? Nun, das ist genau dieses genannte featureLevel. Schauen wir mal in die Änderungen von 5.9 auf 6.0:

• Attribut-Namen duerfen nur die Zeichen A-Za-z/\d_.- enthalten (sonst gibt es eine Warnung)
• das structure propagateAttr Attribut ist per Voreinstellung leer und nicht .*: wenn man ein Struktur-Attribut setzt, dann wird das nicht an die Mitglieder propagiert.

Das ist alles. Warum man hier eine 6.0 und keine 5.10 veröffentlich hat, erschließt sich mir allerdings auch nicht.

Mit dieser Änderung im System, ändert sich also das Standardverhalten der genannten Punkten im System. Das Attribut featureLevel hat nun den Standardwert 6.0 erhalten. Zur Feier des Tages (warum auch immer) wird also ein neues Paket gebaut und auf den Seiten von FHEM bereitgestellt. Am Ende spielt das aber absolut keine Rolle und wäre nichtmal nötig. Warum?

Angenommen, man hat nun irgendwann im Jahr 2019 FHEM 5.9 mit dem Debian-Paket fhem-5.9.deb installiert. Dann bekommt man den Stand, in welchem das featureLevel 5.9 damals als Standard definiert wurde. Aber auf dem Stand ist hoffentlich kein Nutzer stehen geblieben. Denn die Installationspakete dienen lediglich als Einstiegspunkt für eine Neuinstallation. Es wird empfohlen, sofort nach der Installation ein update all durchzuführen, welches alle Dateien des Systems aktualisiert.

Aber was macht update all genau? Dieser Befehl holt sich eine Datei von den FHEM-Servern mit einer Liste von allen in FHEM enthaltenen Dateien. Diese Liste wird dann Zeile für Zeile mit den aktuell auf der Festplatte vorhandenen Dateien verglichen. Unterscheiden sich Dateien, wird der aktuelle Stand vom FHEM-Server geladen.

Und welchen Stand bekommt man dann? Ganz einfach: Den, der letzten Änderung aus der Versionsverwaltung (siehe oben). Wobei das nicht ganz richtig ist, da diese Datei auf dem FHEM-Server nur einmal am Tag erstellt wird, aber das spielt hier gerade eine untergeordnete Rolle und kann für die Erklärung igoriert werden.

Zusammengefasst: Egal, welchen Einstiegspunkt (welche Installationsdatei) man genutzt hat, man kommt so immer an den aktuellsten Stand.

• fhem-5.9.deb + update all = Aktueller Stand
• fhem-6.0.deb + update all = Aktueller Stand

Der Stand aus dem fhem-6.0 Paket liegt also irgendwo zwischen 5.9 und dem aktuellen Stand des heutigen Tages. Wo genau? Das kann Dir als Nutzer total egal sein. Denn man macht ja eh direkt ein Update.

Zur Veranschaulichung nehmen wir mal diese Tabelle. Hier siehst Du die Verschiedenen Änderungen (001 bis 009). Bei 003 wurde das featureLevel 5.9 zum Standard erklärt. Bei 006 das featureLevel 6.0. Installierst Du nun fhem-5.9 erhältst Du den Stand 003. Installierst du den fhem-6.0 erhältst Du Stand 006. Mit einem update all kommst Du aber von beiden Ständen auf die aktuelle 009. Es gibt z.B. keine Möglichkeit, von 003 auf 006 zu wechseln. Zumindest nicht, ohne mit SVN zu arbeiten und die Tags direkt auszuchecken.

Somit kann 6.0 gar keine Versionsnummer von FHEM darstellen, denn diese Info spielt absolut keine Rolle. Denn das ganze System mit hunderten Modulen und Icons usw. bekommt dieses “Tag”. Und das entscheidet nur ein Entwickler alleine (Rudolf König). Wäre dies ein wichtiger Moment für eine neue Version, müsste man dies mit allen Entwicklern abstimmen. Dann müsste man ALLE Module ausführlich testen und dann gemeinsam freigeben, falls es keine Fehler gibt. Da dieses Vorgehen aber extrem aufwändig wäre (und man ja eh direkt nach der Installation ein Update durchführen wird) ist dieser Stand aber total irrelevant.

Daher werden große Projekte ja auch in viele kleine Module zerlegt, welche wiederum ihre eigene Version pflegen. Siehe ioBroker mit seinen Adaptern, nodejs mit den npm Paketen, PHP mit den composer Paketen, oder auch Perl (die Grundlage von FHEM). Überall bekommen die einzelnen Pakete / Libraries eigene Versionen und sind einzeln updatefähig. Nur mit diesen vielen einzelnen Versionen kann man auch einen solides Abhängigkeitsmanagement auf die Beine stellen. Aber das ist ein anderes Thema.

Was spricht also dagegen, dass das “6.0” im Namen vom Installationspaket eine Versionsnummer darstellt?

• Es gibt viel zu selten Releases von neuen “Versionen”. Die aktuelle “Version” ist fast ein Jahr alt. Seitdem sind tausende Änderungen veröffentlicht worden, welche viele Fehler beheben oder Features hinzufügen. Warum sollte man diese so lange den Nutzern vorenthalten?
• Es gibt keine Update-Strategie um von dem installierten Stand fhem-5.9 auf fhem-6.0 zu kommen. Mit einem update all überspringt man wie gesagt den in fhem-6.0 enthaltenen Stand (was wie gesagt auch völlig ok ist). Würde es sich um freigegebene Stable-Releases handeln, müsste man doch auch einen Weg und eine Dokumentation bereitstellen, um zu diesem Stand zu kommen, oder?
• Selbst auf der Debian-Seite von FHEM wird darauf hingewiesen, dass diese Paket nur einen Einstieg darstellen. Dort ist dieser Hinweis zu finden: All procedures are intended to create FHEM installations from scratch. Do not use these procedures for updates/upgrades!. Wenn morgen also das Installationspaket fhem-6.1 erscheinen sollte, ist dies für Bestandsinstallationen völlig irrelevant. Mit einem Update kommt man ja eh dort hin.
• Es gibt keine Changelog, was zwischen 5.9 und 6.0 passiert ist. Weiter oben im Artikel sind zwei Punkte aufgeführt, welches Verhalten sich ändert hat. Aber zwischen den Installationspaketen fhem-5.9 und fhem-6.0 liegen wie gesagt tausende Änderungen in hunderten Modulen. Und nicht nur zwei.
• Man kann das featureLevel in FHEM frei konfigurieren. Nichts hält mich davon ab, auf einem beliebigen Stand einfach wieder 5.9 in das Attribut einzutragen. Damit ändert man wie gesagt nur das Verhalten des Systems - die Dateien auf der Festplatte bleiben unverändert und es findet kein Downgrade auf einen älteren Stand statt.
• Schaut man nach, was in $attr{global}{version} steht, findet man nur den Commit aus SVN - von 5.9 oder 6.0 ist dort (logischerweise) nichts zu lesen.
• Das “offizielle” Docker-Image nutzt nichtmal die Installationspakete, sondern installiert den aktuellen Stand aus SVN. Wäre es kritisch, ein Update durchzuführen, würde man damit eine unstable-Version ausliefern. Damit wäre das Docker-Image nutzlos (was es natürlich nicht ist).
• Der update all Befehl müsste den Nutzer warnen oder keine Update durchführen (solange fhem-6.1 nicht existiert).

Was ist aber verwirrend für den Benutzer?

• Auf der Debian-Seite von FHEM wird von einem “Stable” Release und einem “Nightly Build” gesprochen. So sieht es in der Tat so aus, als müsste man auf dem installierten Stand bleiben. Ich gehe davon aus, dass sich das “stable” auf das Installationspaket selbst bezieht (Nutzer werden angelegt, Service eingerichtet, …) und nicht auf dessen Inhalt. Das ist aber nur eine Theorie.
• Es werden Tags in der Versionsverwaltung erstellt. Somit könnte man denken, dass dieser Stand eine besondere Bedeutung hat.
• Auf der FHEM-Download-Seite steht “Last released version”. Das klingt so, als wäre seitdem nichts passiert. Dem ist aber nicht so.
• Bei Freigabe eines neuen featureLevels werden neue Pakete bereigestellt. Das hat aber absolut nichts zu bedeuten. Es ist einfach nur im Workflow so definiert

Was lernen wir daraus?

• Es ist total unwichtig, welches Paket man zur Installation genommen hat (5.9, 6.0 oder den nightly build). Die Angabe im Dateinamen hat keine Relevanz. Nach einem update all ist man mit allen Paketen auf dem gleichen Stand.
• Man sollte sein System mit update all aktuell halten. Bitte arbeite nicht mit dem Stand von Anno 2020.
• Es gibt keine definierten “stable” Versionen. Der aktuellste Stand über update all ist nach FHEM-Workflow “stable”

Ich hoffe, ich konnte etwas Licht ins Dunkel bringen und Du hast verstanden, worum es hier ging. Ich hätte die Diskussion auf Facebook schon viel eher abbrechen sollen. Das war die Zeit nicht wert, da mein Gegenüber auf seine Meinung nach wie vor besteht.

Und ja, per Definition in der Softwareentwicklung ist “fhem-6.0” eine Version. Denn dieses Paket führt zu einem definierten Stand in der Entwicklungs-Historie. Nur arbeitet bei FHEM niemand so und die Information ist ohne jede Bedeutung. Ich hoffe einfach, dass das nicht der Punkt von meinem Diskussionspartner war.

Der Hinweis vom Anfang, dass man kein Update durchführen soll, ist natürlich Quatsch - bitte halte Dein System mit regelmäßigen Updates auf dem aktuellsten Stand.

Zum Schluss noch eine Empfehlung an die FHEM-Entwickler und Webseitenbetreiber:

• Entfernt das “stable” von den Seiten und weist die Nutzer darauf hin, dass man bitte sofort nach der Installation ein update durchführen sollte.
• Entfernt das featureLevel aus dem Dateinamen - was soll diese Information dort? Man könnte genauso gut die Anzahl der enthaltenen Dateien mit in den Namen aufnehmen. Das hätte einen ähnlichen Informationsgehalt für die Nutzer.
• Nennt 6.0 nicht “Version” in euren Forenbeiträgen.