Konzept für ein Versionierungssystem


#1

@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.


Firmwaretagebuch
#2

ich schmeiße einfach mal ein Vorschlag in den Raum…

[Gluon-Versions-Change].[Änderungen-Seitens-FFMSL].[make-Lauf]

Firmwaretagebuch
#3

Ich persönlich bin ein Fan einer sehr zurückhaltenden Nummerierung. Also z. B.

Gluon-Majorrelease.Gluon-Minorrelease.FFMS

Aber da du die Firmware baust, kannst du das frei entscheiden.

Grüße
Matthias


#4

vX.Y.Z

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?


Gluon v2016.2 und ein paar neue Optionen
#5

Die beiden andersherum, vermutlich hast du dich nur vertippt.

Aber so war mein Vorschlag. Mir ist das aber wie gesagt egal. Wenn du die Firmware machst, kannst du das festlegen, wie es dir gefällt.

Grüße
Matthias


#6

Richtig… da ist ein Dreher drin…

ok… dann leg ich das jetzt mal so Fest! :grin:


#7

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.


#8

Release Notes erzeugt man typischerweise aus Commit Kommentaren.


#9

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.


#10

Care to elaborate?

Wir können als Versionsbezeichung auch jeweils einen Haiku nehmen. Das wäre ungewöhnlich. :slight_smile:


#11

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.


#12

Der Doppelpunkt ist halt eher mit anderen Bedeutungen belegt. Spontan fallen mir Portnr und Trenner für Uhrzeit ein. Das Zeichen dort anders zu verwenden, als man es gewohnt ist, kann verwirren. Außerdem mag Windows es wohl nicht sagt googeln. https://stackoverflow.com/questions/10386344/how-to-get-a-file-in-windows-with-a-colon-in-the-filename

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.


#13

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 “-”. :wink:


#14

die Gluon Version ist doch so oder so enthalten… der gesamte Versionsstring währe dann z.b. so wie jetzt auch v2016.1.6+1.1.9

es ging mir eig. nur um das wann zählen wir was hoch…


#15

v2016.1.6b1,v2016.1.6b2,…,v2016.1.6bn


#16

In dem Fall würde ich bei inhaltlichen Änderungen Hochzählen, nicht bei Builds.


#17

Doppelpunkt geht nicht, da verbotenes Zeichen im Windows-Dateinamen.
(siehe https://de.wikipedia.org/wiki/Dateiname#Problematische_und_unzul.C3.A4ssige_Zeichen_oder_Namen)

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.


#18

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


#19

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”.


#20

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.