Gluon v2019.1 released

hexa hat heute das neue Release bekanntgegeben:

We’re proud to announce a new major release of Gluon!

This is the last release to support IBSS and batman-adv v14 compat.
If you’re still using either technology you need to do a migration
during the v2019.1.x release cycle to be able to update to a future
Gluon major release (v2019.2 and later).

This release includes:

  • batman-adv kmod coexistence
    to enable scheduled migrations between batman-adv kmods

  • Outdoor Mode
    to allow outdoor channel usage for when installing devices
    outdoors

  • Device Deprecation
    to decide how you want to handle device deprecation downstream

  • Hoodselector: Geolocation mode
    to continously reevaluate and migrate between domain based
    on the node’s geolocation

As always you should check the release notes up on Read the Docs:

Gluon 2019.1 — Gluon 2019.1 documentation

– hexa-

2 „Gefällt mir“

Schade und danach muss man sich einen fork erstellen um weiter compat14 nutzen zu können?
Ich denke es wird eine Menge Communitys geben, die eine Migration nicht durchführen können zwecks Personal, Zeit und Ressourcen. Aber bei Gluon ist man ja als firmware Bäcker leid gewohnt :slight_smile:

2 „Gefällt mir“

Nicht unbedingt.

Da Gluon ja in einem Git repository gepflegt wird kannst du jederzeit zu einem Versionsstand zurückkehren, der noch v14 unterstützt. Durch den Release von 2019.1 wird v14 ja nicht automatisch in älteren Versionen deaktiviert oder unnutzbar gemacht.
Einen eigenen Fork benötigst du nur, wenn du Funktionalitäten und Fixes aus neueren Gluon Versionen in ältere Versionen zurückportieren willst.
Das ist allerdings nicht ganz trivial und der mit der Zeit stetig wachsende Aufwand hierfür steht nicht im Verhältnis zur Zeit und dem Aufwand, die man durch das Unterlassen der Migration auf v15 einspart.

Der Zyniker in mir meint, dass in diesen Communities ja auch einfach das Updaten der Firmware eingestellt werden kann um nicht weiter Personal, Zeit und Ressourcen zu binden.

Mit den angebotenen Werkzeugen ist eine Migration weniger schwierig als es zunächst scheinen mag. Ich spreche da aus Erfahrung.

Nein, das neue Gluon kann Batman IV in Compat14 und Compat15 mit einer Firmware bedienen. Es kann „live“ beim Booten umgeschaltet werden.
Das ist wichtig, um einen Wechsel hinzubekommen „zu festem Zeitpunkt“.
(Vermutlich wird Batman14 aber später in Gluon 2019.2+ wegfallen.)

Ich bemängele breaking changes ja generell gerne, aber hier sehe ich nicht wirklich den Hebel: compat14 ist mittlerweile nicht mehr „gut abgehangen“, es riecht schon unappetitlich. Der Hinweis auf „v14 ist nun wirklich tot und verwest, bitte geht weiter, hier stinkt es“ ist deutlich und rechtzeitig angebracht, denn auch Gluon v2019.1 unterstützt es noch. v15 wird aktiv weiterentwickelt, v14 ist eine Sackgasse.

Und ja, wir sind noch auf v14, weil v15 bei der Einführung nach zu viel Schmerzen klang (>1 Core, unterschiedliche MTU — v15 schien initial einfacher Gründe zum crashen denn zum funktionieren zu finden). Migrations-FW, auf Basis v2018.2.x, ist im Test, denn 2013 ist einfach doch nun zu lange her.

Aus meiner Sicht – been there, done that – ist es nicht wirklich sparsamer bzgl. der Ressourcen, einen Fork weiterzupflegen. Zumal spätestens beim nächsten Kernelwechsel keiner der Patches mehr paßt, die Zeit für den eigenen Fork kann man imho besser anderswo einsetzen. Aber es bleibt Deine Entscheidung :wink:

@steneu Bitte aktualisiere die URL zu den Release Notes in deinem Post noch auf Gluon 2019.1 — Gluon 2019.1.3 documentation. Die haben wir gerade erst live geschaltet, dort tauchen auch Änderungen auf die im v2019.1.x Branch landen.