Der erste Build der 2.0.0 liegt auf fw.4830.org, ab 2.0.0~1 dann auch mit korrekter Lokalisierung 
Installationsroutine scheint soweit zu tun, jetzt wäre noch ein paar Tests im Betrieb sinnvoll: happy testing!
Ah, bitte beachtet, daß es auf 2.0, Gluon v2023.2.5-based, nur von 1.9, Gluon v2023.1.2-based, oder v2022.1.x, bei uns übersprungen, geht. Bestandsgeräte mit 1.4er Firmware, Gluon v2021.1.x-basiert, brauchen also vor 2.0 erstmal die 1.9. … die wir auch etwas testen sollten!
Ich hatte gestern auf der Autobahn (leider) viel Zeit zu überlegen; zwei Punkte möchte ich zur Diskussion stellen:
-
Ein (allerletztes) 1.4er Update (Gluon v2021.1.x) für alle Geräte, die danach bei Gluon rausfallen: dieses setzt den Autoupdater-Zweig auf »end-of-life« — auch, damit diese Geräte statistisch einfach erfaßt werden können und klar wird, daß es keine Updates mehr geben wird. Man könnte auch überlegen, an den Knotennamen »-EOL« anzuhängen, um das Problem noch deutlicher zu machen. EDIT: Ideengeber.
-
Angleichen der Autoupdater-Zweige: »tng« wird zu »rawhide«, unserer jeweils aktuellen Testversion, »master« zu »tng«, was ja für die nächste geplante Firmware steht. Daß wir mal zwei in der Pipeline haben ist zugegebenermaßen ungewöhnlich, aber nunja.
Es wurde »deadend«, Bindestriche im Namen mag der Autoupdater nicht. Es gibt nun auch eine Seite auf unserer Homepage zum Thema, im Menü unterhalb »Firmware« verlinkt.
In der Karte sieht’s dann so aus:
@Klaus.P und @bjoerrrrn, bitte beachtet das geänderte Verhalten, ab 1.4.0~167 sollten D5-Knoten (nutzt Minden) nach mid geschoben werden und bei EOL-Geräten wird an den Namen eben ein »-EOL« angehängt und der Firmwarebranch auf »deadend« geändert. 841er und Co. eignen sich daher nur bedingt für Migrationstests 1.5-LIP ⇒ 1.4-4830 ⇒ 1.9-4830