@descilla hat im Thema Verbesserungsvorschlag Kommunikation dankenswerterweise die immer mal wieder unterschwellig gebliebene Diskussion um ein Versionierungskonzept für unsere Firmware entfacht:
Den letzten, eingeklammerten Satz habe ich nun zum Anlass für diese Antwort mit einem eigenen Thema genommen.
Wie kreieren wir ein Versionierungssystem, dass sowohl AnwenderInnen verstehen, jedoch nicht zu platt für die EntwicklerInnen ist? Das aktuelle System schafft den Ausgleich der Interessen nicht.
Also du meinst beispielsweise:
Position X bei Wechsel von v2016.1.5 auf v2016.1.6 hochzählen.
Position Y bei Wechsel von v2016.1 auf v2016.2 oder von mir aus v2016 auf v2017 hochzählen.
Position Z bei Änderungen von uns aus z.b. Site-Conf, Pakete etc…
Muss gestehen das gefällt mir sogar noch besser…
Gruß Marius
@MPW würdest du die Beiträge zur Version Hier hin verschieben?
Also ich fände es gut wenn die Gluon Version 1:1 in der FW Version enthalten wäre.
Dann noch eine Buildnummer sollte reichen. Damit es lesbarer wird vielleicht auch kein Punkt als Trennzeichen zwischen Gluon und Build
also z.b:
< GluonVersion > : < Build >
Dann müssen wir auch keine Annahmen über die Struktur der Gluon Versionsbezeichnung machen. In dem vorgenannten Beispiel x.y.z wäre das nämlich andernfalls nicht eindeutig falls es Gluon Minor oder Bugfix Versionen gibt.
Release Notes finde ich knorke. Da Gluon afaik mindestens eine Minorversion hat wäre x.y.z doof da x und y schon von gluon kommen. Ein “:” als Trennzeichen ist auch eher ungewöhnlich und potentiell problematisch. “_” oder “-” haben sich bei so was bewert, ggf. noch “~”. Aus der Buildnummer kann man imho ja auch Null Informationen entnehmen, außer das Version X neuer oder älter ist als Version Y. Vorschlag: XXXX.Y-Z wobei XXXX.Y der Gluon Nr entsprechen. Z sind Münster spezifische Änderungen und werden pro Gluon Version hochgezählt, angefangen wird dabei immer bei 1.
Eine wichtige Funktion unterschlägst du: Man kann damit den exakten Softwarestand bestimmen da hier keine Gefahr besteht das jemand da vergessen hat etwas zu inkrementieren.
Ich dachte aber in der Tat eher an Verwechslungen und ähnliches als Probleme mit dem OS o.ä. aber wenn die Dateien nicht auf Windows funzen wäre das für die Zielgruppe natürlich auch suboptimal.
Naja, wer eine Versionsbezeichnug als URL parst ist irgendwie selbst schuld.
Aber mit Dateinamen hast du natürlich recht, da wäre ich dann aus rein ästhetischen Gründen für ein “-”.
Doppelpunkt geht nicht, da verbotenes Zeichen im Windows-Dateinamen.
(siehe Dateiname – Wikipedia)
Wenn man Builds nicht mit hochzählt, hat man ggf. Probleme mit der Eindeutigkeit. Wir sollten jedenfalls nicht unterschiedliche Dateien mit potenziell gleichen Namen erzeugen.
In Warendorf habe ich immer die Gluon-Version genommen, und mit „-“ was hinten dran gehängt. Bei neuer Gluon Version wurde das immer eine [gluon-version]-0.exp$(shell date ‚+%Y%m%d‘), die ausprobiert wurde, und wenn das gelaufen ist, dann wurde daraus eine [gluon-version]-1 …
Für den Fall, dass ich was geändert habe, wurde daraus eine [gluon-version]-2.exp$(shell date ‚+%Y%m%d‘), die im stable dann schließlich eine [gluon-version]-3 wurde.
Auf die Art haben auch immer die Updates von testing->stable schön geklappt, denn wenn ein testing fertig war, habe ich das testing geschlossen, in dem ich ein weiteres (fast identisches) Update im testing gebaut habe, dass den autoupdater auf „stable“ umgestellt hat. Siehe dazu hier und vergleichbare…
Deswegen ist jede Build das inhaltliche Änderungen hat eine (minor) Version. Zweimal nacheinander den Buildserver anzuwerfen ohne was zu ändern wäre ansonsten aber ein „neues Build“.
Es ist ja auch immer ein neuer Build, denn die Builds sind, soweit ich weiß, nicht reproduzierbar (in Hinsicht auf md5sum und so). Man muss ja nicht immer alles Builds veröffentlichen.
