Wichtig beim Umstieg auf v2.9

[wvhn]

Hallo zusammen,

beim Umstieg auf v2.9 kann es Probleme mit der Konfguration geben, wenn veraltete Dateien aus früheren Installationen mitgeschleppt werden. So gab es z.B. vor v2.8 im Verzeichnis /widgets eine Datei "forms.html" für die Bedienelemente. Heute wird "forms.html" mit ganz anderem Inhalt als zentrales Element der Config-Seiten benötigt. Solche Dateien (wie auch base.html und system.html) dürfen nicht in die neue Visu übernommen werden, denn dann gibt es Chaos.

Empfohlene Vorgehensweise:

• das ganze Paket aus dem Master in einen neuen (!) Ordner clonen, z.B. "smartvisu-new"
• einen neuen eigenen Ordner "smartvisu-new/pages/<Deine Seiten>" als Kopie des Ordners /pages/_template anlegen und dann nur die Seiten hinein kopieren, die echt zu Eurer eigenen Visu dazu gehören.
• ggfls. "rooms_menu.html" aus der bisherigen Installation übernehmen, oder besser nur die Listen-Elemente in die neue rooms_menu.html kopieren
• Wer Quad nutzen möchte, kann sich auf den Doku-Seiten unter Design-Quad ansehen, was für den Umstieg zu tun ist. Oder einfach das umfangreiche "example4.quad" kopieren und anpassen

Viel Erfolg!

Gruß Wolfram

[Sisamiwe]

Hallo,
smai wvhn Onkelandy Tolle Arbeit! Danke.

Ich bin dann auch gleich umgestiegen bzw. habe meinen 2.9 develop auf 2.9 master gewechselt.
Der template checker wirft mir nun bei allen basic.print einen Fehler aus. Der Parameter für "format" löst den Fehler aus.
Ein Beispiel:

{{ basic.print('', 'raumtemp.aussen.nord.min_today', 'temp') }}

oder

{{ basic.print('', 'raumtemp.aussen.nord.max_today', '°') }}

Gleiches habe ich auch bei %. Hat sich das geändert?

Danke!

[wvhn]

Danke für die Anerkennung!

Das scheint ein bug im Templatechecker oder im docstring des widgets zu sein. Wir hatten auf Wunsch eines einzelnen Herren noch last minute ein Feature in basic.print aufgenommen und die Prüfung der Doku-Seiten mit dem Templatechecker nicht wiederholt. Sorry.

Die Funktion von basic.print ist aber laut all unseren Tests trotzdem in Ordnung. Anwendungen siehe inline-Doku von basic.print.

Gruß Wolfram.

[wvhn]

Ein Fix ist jetzt im master branch verfügbar. Wir warten ab, ob noch weitere Probleme hinzukommen und entscheiden dann, wie wir mit der Versionierung umgehen.

Gruß Wolfram

[PatrikG]

Ich würde das so machen:

1. Es gibt kein festes Release, sondern nur den Master-Branch als "last stable". Der Link auf der Homepage sollte auch auf diesen verweisen.
2. Eine Fehlerbehebung wird zeitnah in den Master, und falls erforderlich auch in den Develop, commited und erhöht den Patchlevel (Revisionsnummer), z.Bsp. 2.9.1
3. Eine Verbesserung/Erweiterung wird nach Bedarf/Wunsch in den Master, und falls gewünscht auch in den Develop, commited und erhöht den Minorlevel (Nebenversionsnummer) und setzt den Patchlevel auf 0, z.Bsp. 2.10.0
4. Der Develop-Branch ist die neue Hauptversion (unstable) und erhält den nächsten Majorlevel (Hauptversionsnummer), z. Bsp. 3.0.0. Möchte man den Develop-Branch ebenfalls versionieren, dann könnte man dazu die Buildnumber anfügen, welche bei jedem Commit erhöht wird, z.Bsp. 3.0.0-0001

Ich kenne mich mit Github leider zu wenig aus, aber eventuell gibt es dort auch bereits auch eine automatische Versionierung.

Das i-Tüpfelchen wäre dann noch eine konfigurierbare Versionsprüfung (täglich, wöchentlich, monatlich, gar nicht) mit automatischer Updatefunktion. 😁

[Msinn]

PatrikG Das wäre aus meiner Sicht für den Support ein Nightmare. Der Supporter hat dann keine Idee mehr was der fragende bei sich im Detail installiert hat.

Das Weglassen eines Releasemanagements kann aus meiner Sicht keine Lösung für irgendwelche Probleme sein.

[Onkelandy]

Ich denke, es war extrem verwirrend, beim develop Branch von Version 2.9 zu reden. Fraglich ist aber natürlich, ab welchem Zeitpunkt man den Release machen hätte können bzw. machen kann.

Zum einen wird es Patches geben, zum anderen neue Features und dann auch noch große Änderungen wie Twig, jquery, etc. Updates. Im Großen und Ganzen wäre das für mich dann die oben angeregte Unterscheidung von Patch (Revision) bei Fehlerausbesserung, Nebenversion bei einer gewissen Anzahl an Neuerungen (kann man imho durchaus aus dem Bauch entscheiden), Hauptversion bei Änderungen im technischen Grundbau.

Nach der Logik bräuchte es dann aber unterschiedliche Branches und der aktuelle Release hätte 3.0 sein müssen auf Grund des Umstellens der Widgets, etc. Das Einfachste wäre daher wohl, bei 2.9 develop zu bleiben, bis es Zeit für den 3.0 Release wird...?

[Msinn]

Ich würde dafür plädieren die Versionsnummer im develop branch weder auf 2.9 zu lassen noch bereits auf 2.10 zu setzen. Ich habe die eindeutige Erkennbarkeit bei SmartHomeNG so sichergestellt, dass die Versionsnummer im develop Branch einen Buchstaben nachgestellt bekommt, der sich auch ändern kann, falls für bestimmte Funktionalitäten ein bestimmter develop Stand nötig ist (minimum Version für Plugins). Im Moment ist bei SmartHomeNG der master auf v1.6 und develop auf v1.6b. Beim nächsten Release wird der Master auf v1.7 gehen und zum selben Zeitpunkt setze ich dann im develop die Version auf v1.7a.

Damit kann man sauber auseinander halten vor welchen Versionen/Ständen man redet. Diese Benennung des SV develop als 2.9 fand ich auch extrem unglücklich.

[wvhn]

Aktuell haben wir nach dem Release nur den Templatechecker gepatcht und kleinste Verbesserungen in der Doku gemacht. Also nichts Funktionsrelevantes.

Vorschlag:
Wir warten jetzt mal ab, ob aus der Anwendung von v2.9 Fehler hochkommen, die wir noch fixen müssen. Zeitraum 4 Wochen. Was bis dahin kommt, packe ich in eine v2.9.1. Wenn etwas Gravierendes hochkommt, das schnell gepatcht werden muss, gibt es das Nebenrelease eben etwas früher.

Im develop stehen die Tags bei den Issues alle auf "later". Ich werde diejenigen, die wir bearbeiten, auf "next" setzen und wir werden nicht mehr von irgendwelchen Versionsnummern reden, OK?

Die Idee mit 2.9a finde ich auch gut, aber wir sollten erst einmal wissen, wie groß der nächste Schritt werden wird. Zum Beispiel kann beim Upgrade auf Twig v3.x ein so großer Änderungsbedarf entstehen, das die develop-Version für eine ganze Zeit praktisch nicht benutzbar ist. Eine Bezeichnung v2.9a wirkt da vielleicht etwas zu sehr verharmlosend.

Pull-Requests für Verbesserungen sollen bitte ausschließlich ins develop gehen. Dann kann ich diese dort mergen und testen, bevor sie im master freigegeben werden.

[Msinn]

Ich habe 1.6a gemacht, gerade weil ich nicht weiss wie goß der nächste Schritt ist. Das wurde dann eine 1.6.1 (reines Plugin Release), hätte aber auch bereits eine 1.7 sein können. Die Release Nummer muss bei dem Vorgehen erst beim Release festgelegt werden. Es geht bei shng vorwiegend darum deutlich zu machen, dass jemand auf dem develop branch unterwegs ist (vieleicht auch ohne sich dessen noch bewusst zu sein).

[wvhn]

Guter Punkt. Ich hab das jetzt in die version-info.php übernommen.