Ich kann was Versionierung angeht das hier als Leitfaden empfehlen:
Für Düsseldorf verwenden wir z.b. das folgende Schema:
v1.2.5-r2
Also [Versionsnummer]-r[Buildnummer], so können wir für die selbe Version mehrere Builds haben, normalerweise macht man nämlich nur neue Versionsnummern wenn sich was ändert :).
Ich weiss nicht, ob Du gelesen hast, was ich geschrieben habe.
Aber um aus dem von Dir refernzeierten Leitfaden zu zitieren:
A normal version number MUST take the form X.Y.Z where X, Y, and Z are
non-negative integers, and MUST NOT contain leading zeroes. X is the
major version, Y is the minor version, and Z is the patch version.
Each element MUST increase numerically. For instance: 1.9.0 → 1.10.0 → 1.11.0.
Und genau das leistet der Autoupdater derzeit leider nicht.
Denn für ihn ist „1.10.0“ < „1.9.0“
Denn es findet kein numerischer Vergleich (und damit notwendigerweise auch vorher eine syntaktische Analyse des Versionsstrings) statt. Sonder ein alfanumerischer Vergleich, Buchstabe für Buchstabe. (Was bei UTF8 passieren würde möchte ich gar nicht wissen…)
Ich möchte an dieser Stelle auf das Versionierungskonzept der Frankfurter verweisen:
Vieleicht mag @Jason dazu etwas aus der Praxis sagen.
Der Autoupdater folgt afaik den Debian-Versionsvergleichsregeln:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a.
Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero.
These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted.
Wir hier in Frankfurt verwenden seit neuestem folgendes Versions-Schema:
<Versionsnummer>-<Branch Name>-<Branch Buildnummer>
So wie ich den Autoupdater kennengelernt habe, und das hat bei mir weh getan, so vergleicht er von links nach rechts die einzelnen Abschnitte, bis er einen Unterschied festgestellt hat.
Der Vergleich findet zeichenweise statt, solange es sich um keinen numerischen Ausdruck handelt.
@adorfer Daher ist für den autoupdater „1.10.0“ > „1.9.0“ (er stellt fest, das 10 > 9 ist)
Treffen bei einem Vergleich ein Buchstabe bzw. ein Zeichen und die erste Ziffer eines numerischen Ausdruckes aufeinander, so wird die ASCII-Tabelle zur Hand genommen.
Alles was keine Ziffer ist wird als (Trenn-)Zeichen interpretiert und einzeln nach der ASCII-Tabelle ausgewertet.
Da fehlt irgendwie eine Schlüssel-Information, hab aber keine Ahnung welche.
Kannst Du etwas Genaueres zur Behandlung und zur Manipulation der Manifestdatei in Münster sagen?
Mit Manipulation meine ich, dass ich, wie oben vorgeschlagen in der Manifestdatei die Version auf z. B. 2016.1.y ändere, obwohl es nur 2016.1.5 ist. Man spielt also eine neuere Version vor.
Das haben wir früher auch so gemacht, allerdings ist das sehr unpraktisch wenn mal jemand von Stable zu Beta oder andersherum wechseln möchte, daher läuft es nun so:
So einfach ist das bei uns nicht. Wir haben das gerade deshalb so gemacht, damit man sehr einfach kreuz und quer, rauf und runter wechseln kann.
Siehe: DiesUndDas/konzept_versioning_policy.md at master · oszilloskop/DiesUndDas · GitHub
Bei uns sieht das Versions Schema letztendlich dann so aus:
1.11-stable-12 (neues Datum)
1.10.3-test-62 (nicht so neues Datum)
1.10.2.1-dev-106 (älteres Datum)
1.10-stable-11 (ganz altes Datum)
Das ist aber ein anderes Thema, da kann man Tage, ja Wochen bis zur Ohnmacht drüber philosophieren …
Vielleicht macht es auch Sinn, einfach die Anforderungen runterzuschrauben? Mit einem Schema 0.M.m~build und 0.M.m-rel kommt der bestehende Code doch klar, auf welcher Seite des Bildschirms existiert dann ein Problem? [M=Major, m=minor]
Ich habe vor Zeiten auf ein banales Timestamp (YYYYMMTThh) umgestellt mit einem suffix für sta/bet/exp.
Wer mehr wissen möchte, der soll gefälligst ins Git schauen. Außer den jeweiligen community-MaintainerInnen blickt in „1.0.51-rc3-stable“ sowieso niemand durch und alle anderen müssen (wer hätte es nicht anders vermutet) ins Git schauen.
Aber das ist doch totaler Mist, genau wie so etwas hier:
v1.10.3-test-83, das baut dann laut Daten in der Karte auf gluon-2016.1.4 auf.
Wenn dann mal, wie öfters, der Fall besteht bei Gluon Problemen zwischen den Communities zu vergleichen wird das selbst für an sich eingeweihte enorm schwierig.
Ist es wirklich zu viel verlangt dem Gluon Release Tag auf dem die Firmware basiert aufzunehmen?
Dazu falls fünf Minuten je Release Zeit sind noch eine Priese Doku, weil man im git bei weitem nicht alles sehen kann:
https://wiki.freifunk.net/Freifunk_Aachen/Firmware#Stable
Meine Frage ist beantwortet. Ihr könnt gerne noch über Versionsschemata diskutieren, ich wollte nur wissen, warum die Knoten bei uns nicht ziehen. Das ist gelöst.
Provokante Frage, direkte Antwort: Ja.
Wir bauen nicht stumpf vanilla Gluon mit eigener site.conf, aktuell patchen wir auch das OpenWRT unter 2015.1.x. Insofern ist die Gluon-Basis nur ein Aspekt, und der wird in der minor number ausgewiesen. Unter anderem würde es die Nutzer zurecht verwirren, wenn wir Mitte 2016 eine Firmware aus 2015 rausbrächten … Suffixe für stable & Co. machen wir nicht, das würde einen neuen Build implizieren (oder andere Werte im Build und im Manifest) und damit etwas freigeben, was so nie getestet wurde. Aber das hat mit dem Versionsvergleich schon nichts mehr zu tun.
Klingt vielversprechend, habt ihr eine Doku was ihr baut?
Könnte mir gut vorstellen, dass es sich lohnt etwas davon zu übernehmen.
Da OT, Info per PN.
Hallo, in einem neuen Image habe ich dei Versionsbezeichnung geändert. Ich wollte vorne ‚rhb‘ stehen haben, damit meine Versionen nun der Liste zusammen stehen. Aber: ‚r‘ ist natürlich kleiner als ‚v‘. Ich würde daher auch für ein Check nach Datum plädieren. Zum Beispiel anhand des Manifestes. Dann könnte man auch ohne neuen Version ein Downgrad initialisieren, indem man ein Manifest mit neuem Datum versieht.
Du kannst auch einmalig das Manifest abändern, um die Version kleiner zu machen. Dazu die neue Version in die Datei kompilieren und im Manifest vorne die Version mit einem zz versehen oder so.
Dabei dann aber ungemein vorsichtig sein und beispielsweise zusätzlich den Download Server oder die benötigen keys ändern.
Ansonsten ziehen deine Kisten jede Stunde erneut das Update.
Da ich das Thema gerade altlastig reinbekomme (Legacy-Firmwares tragen Versionsnummern wie hintertupfing-1.01, niederdeich-1.05, mit Multidomain (post-Gluon v2018) soll es dann mit 1.2, 1.3, usw. weitergehen): wie bekomme ich es hin, daß eine FW „niederdeich-1.05“ die Firmware „1.2“ als neuer ansähe?
Fake-Manifest bauen (suchen, ersetzen im Manifest)
gepatchtes Manifest für diese Knoten mit einer rewrite-rule ausliefern.
Also quasi cp -p stable.manifest stable.manifest.old ; awk -v vers=zzz-6.6.6-stable <stable.manifest.old >stable.manifest '{if(NF==5) {printf("%s %s %s %s %s\n", $1, vers, $3, $4, $5);} else print $0;}'?
Bsp.:
ffgt@tomjon:~/build$ head gluon-ffgt-v2021.1/output/images/sysupgrade/stable.manifest-1.4.0~16
BRANCH=stable
DATE=2022-05-13 00:57:07+02:00
PRIORITY=0
tp-link-tl-wdr3600-v1 1.4.0~16 d0c05fcb9cf40c2e057de9d8eed41eaddb1b3c276bb778678a0efefd7fdc5c44 5701636 gluon-4830-1.4.0~16-tp-link-tl-wdr3600-v1-sysupgrade.bin
d-link-dap-1330-rev-a1 1.4.0~16 6adc0f07e488f416cb7381120ae1ac1e870401c24b88c4f25d930342f1688c07 5701636 gluon-4830-1.4.0~16-d-link-dap-1330-rev-a1-sysupgrade.bin
tp-link-cpe210-v2 1.4.0~16 3a37b789a2abc1ce8f6bb2a79900b324ac41b7e6d3cbbd5fbe62adae379e8314 7803808 gluon-4830-1.4.0~16-tp-link-cpe210-v2-sysupgrade.bin
tp-link-cpe210-v2.0 1.4.0~16 3a37b789a2abc1ce8f6bb2a79900b324ac41b7e6d3cbbd5fbe62adae379e8314 7803808 gluon-4830-1.4.0~16-tp-link-cpe210-v2-sysupgrade.bin
tp-link-wbs210-v1 1.4.0~16 2f831e543b868e95783e456d5980403f7210b7f3329ecfe951c3ab7d9bcb650d 7802999 gluon-4830-1.4.0~16-tp-link-wbs210-v1-sysupgrade.bin
tp-link-wbs210-v1.20 1.4.0~16 2f831e543b868e95783e456d5980403f7210b7f3329ecfe951c3ab7d9bcb650d 7802999 gluon-4830-1.4.0~16-tp-link-wbs210-v1-sysupgrade.bin
ffgt@tomjon:~/build$ awk -v vers=zzz-6.6.6-stable <gluon-ffgt-v2021.1/output/images/sysupgrade/stable.manifest-1.4.0~16 '{if(NF==5) {printf("%s %s %s %s %s\n", $1, vers, $3, $4, $5);} else print $0;}' | head
BRANCH=stable
DATE=2022-05-13 00:57:07+02:00
PRIORITY=0
tp-link-tl-wdr3600-v1 zzz-6.6.6-stable d0c05fcb9cf40c2e057de9d8eed41eaddb1b3c276bb778678a0efefd7fdc5c44 5701636 gluon-4830-1.4.0~16-tp-link-tl-wdr3600-v1-sysupgrade.bin
d-link-dap-1330-rev-a1 zzz-6.6.6-stable 6adc0f07e488f416cb7381120ae1ac1e870401c24b88c4f25d930342f1688c07 5701636 gluon-4830-1.4.0~16-d-link-dap-1330-rev-a1-sysupgrade.bin
tp-link-cpe210-v2 zzz-6.6.6-stable 3a37b789a2abc1ce8f6bb2a79900b324ac41b7e6d3cbbd5fbe62adae379e8314 7803808 gluon-4830-1.4.0~16-tp-link-cpe210-v2-sysupgrade.bin
tp-link-cpe210-v2.0 zzz-6.6.6-stable 3a37b789a2abc1ce8f6bb2a79900b324ac41b7e6d3cbbd5fbe62adae379e8314 7803808 gluon-4830-1.4.0~16-tp-link-cpe210-v2-sysupgrade.bin
tp-link-wbs210-v1 zzz-6.6.6-stable 2f831e543b868e95783e456d5980403f7210b7f3329ecfe951c3ab7d9bcb650d 7802999 gluon-4830-1.4.0~16-tp-link-wbs210-v1-sysupgrade.bin
tp-link-wbs210-v1.20 zzz-6.6.6-stable 2f831e543b868e95783e456d5980403f7210b7f3329ecfe951c3ab7d9bcb650d 7802999 gluon-4830-1.4.0~16-tp-link-wbs210-v1-sysupgrade.bin