Hallo Milo

es ist schön, dass Du dieses Problem nun auch erkennst.

Tja, in manche Falle muss man wohl selbst reinrennen. Davon abgesehen lassen mich deine folgenden Ausführungen vermuten, dass wir "damals" aneinander vorbei geredet haben.

Ich hatte es beim Update-Checker auch und musste mir, nachdem Du ja nicht abzubringen warst, was einfallen lassen.

Hier ist wohl der Punkt, an dem ich dich falsch verstanden hatte. Da ich unsere alte Unterhaltung dazu gerade nicht wiederfinde, sei hier nochmal meine Haltung zusammengefasst.

1. Den Forenbetreibern gegenüber, also extern, die einschätzen können müssen, ob sie eine neue Version einspielen sollen oder nicht, brauchen wir eine Versionsbenennung, die einen Betastatus erkennen lässt.
2. Diese Benennung mit "beta0" – das ergibt sich aus meiner jetzt selbst erlangten Erfahrung – könnten wir intern durchaus weglassen, um uns nicht die Versionsnummerierung und deren Vergleich zu verkomplizieren.

Eine Versionsnummer kann, wenn wir uns auf ein konsistentes Schema geeinigt haben, ohne das Wort "Alpha" oder "Beta" in der Versionsnummer auskommen, im Namen jedoch weiter diese Ergänzung tragen.

Ich versioniere bei neuen Projekten nur über das Datum.

Das fände ich ein bisschen krass. Ich befürchte auch, dass das so manchen updatewilligen Forenbetreiber verwirren würde.

Bei alten Projekten habe ich eine Kombination aus Version und Build. Die version ist ein einfacher DOUBLE bspw. 3.5 und das Build ist ein Integer und wiederum das Datum. So komme ich in der Summe auf etwas wie 3.5.20160523.

Dieses Schema ist grundsätzlich auch auf eine Versionsnummer 2.3.7 oder 4.0.0 anwendbar. Vorteil deines Verfahrens ist die Anwesenheit des Zeitstempels, der als weiteres Vergleichsmerkmal herangezogen werden könnte. Probleme gäbe es nur in einem Fall wie bei den Versionen 2.3.6 und 2.3.6.1, wenn mir die gemachten Fehler sofort aufgefallen und beide Versionen am selben Tag veröffentlicht worden wären.

Wieso liegen eigentlich über zwei Wochen (18.07.2016 und 04.08.2016) zwischen den Versionen? In meiner Erinnerung und auch nach dem Datum des Threads kamen beide Versionen tatsächlich am selben Tag (04.08.2016) heraus. Bei Github wird wohl das Datum des getaggten Commits benutzt, auch wenn der schon Wochen vor dem Erstellen des Releases eingefügt wurde.

Verwirrend!

2. Den Bohei

Das Wort Bohei kannte ich gar nicht...

Mir war bis soeben nicht klar, dass es das Bohei ist.

Buchstaben in der Versionsnummer beiseite lassend

Ja, dass würde vieles erleichtern.

Nunja, das habe ich mittlerweile eingesehen. Wir brauchen eine Nummerierung, deren Fortläufigkeit durch ihr Schema sichergestellt ist und die irgendwie an das bestehende Schema angefügt werden kann, um nicht die Hälfte der Forenbetreiber wegen Verwirrung zu verlieren. Das Schema vollständig zu verändern ist meiner Meinung nach die schlechteste Option.

Mit dem geplanten Sprung auf Version 2.4 bietet sich eine neue Festlegung an, ohne dabei allzuviel Scherben zu hinterlassen. Im Folgenden eine Aufzählung von Versionsschemata, die Prereleaseversionen (Alpha, Beta, auch Delta (RC)) berücksichtigen (oder auch nicht), die ich kenne. Der tatsächliche Release soll der 2.4-er werden.

1. Testversionen werden im 2.3.9.x-er Bereich vor die 2.4 einsortiert. Das könnten wir so kommunizieren, wir müssten nur höllisch aufpassen, nicht selbst durcheinander zu kommen.

2. Testversionen werden im 2.4.0.x-er Bereich einsortiert, der erste Stable Release des Zweiges wird als 2.4 (ohne Anhängsel) oder als 2.4.1 veröffentlicht. Weitere 2.4-er Versionen sind ausschließlich Fehlerbehebungen. Bei Einführung eines neuen Features wird die Versionsnummer auf 2.5 angehoben.

3. Testversionen werden mit ungeraden Nummern (z.B. 2.4.1.x) geführt, das dazugehörige Stable Release wäre dann die 2.4.2. testversionen des nächsten geplanten Releases liefen unter 2.4.3.x, der Stable dann 2.4.4.

4. Das von dir verwendete Schema mit dem angehängten Datum. Eine eindeutige Markierung als Testversion ist in der Versionsnummer nicht möglich. Im oben beschriebenen Fall 2.3.6 und 2.3.6.1 – so selten der auch eintreffen mag – hieße es aber wieder ein weiteres Merkmal (eine Ziffer) anzuhängen.

5. Statt des Datums kann auch eine Buildnummer, z.B. die eines SVN-Commits, an die Versionsnummer angehängt werden. Auch hier erfolgt dadurch keine Markierung als Testversion. Davon unabhängig steht uns mit Git eine solche fortlaufende Nummerierung nicht zur Verfügung. Stattdessen den Hash zu benutzen wäre möglich aber noch weitaus verwirrender als alle anderen beschriebenen Schemata.

6. und letztens. Hier und jetzt wäre die Möglichkeit einer nummerierten Liste schick gewesen.

Mir persönlich würde Punkt 1 oder 2 am besten gefallen. Gegenüber den installations- und updatewilligen Forenbetreibern sollte dennoch, wie ich ganz oben schon schrieb, ein Name, in dem z.B. "beta" enthalten ist, kommuniziert werden. Bei der Benutzung der Schemas 1 könnte dann aber auch zur Verwirrung führen, dass die Version 2.3.9.5 gleichzeitig die 2.4.beta5 ist.

So richtig perfekt für die gleichzeitige konsistente Nummerierung und verwirrungsfreie Kommunikation ist mMn keine der Lösungen.

Tschö, Auge