Versionsnummern bei mehreren Versionszweigen

[Uwe Raabe]

Obwohl das Thema laut Suchfunktion ja schon behandelt wurde, möchte ich hier gerne ein paar Meinungen von euch zu diesem Thema einsammeln. Man selbst hat ja manchmal nur einen eingeschränkten Sichtraum und da helfen ein paar fremde Standpunkte sicher weiter.

Jahrelang habe ich bei meinen Projekten die verbreitete Major.Minor.Release.Build Nummerierung benutzt. Dabei war das Hochzählen der Nummern für die Major/Minor-Werte eher politisch motiviert als sachlich gerechtfertigt. Darunter allerdings war immer (zumindest theoretisch) gewährleistet, daß Versionen mit gleichem Major/Minor auf- und abwärtskompatibel waren was die externen Daten (Dateiformat, Datenbank) betrifft. Soll heißen, eine mit V2.1.11.608 beschriebene Datei/Datenbank war auch mit einer V2.1.8.412 noch zu bearbeiten. Sobald sich das Dateiformat in irgendeiner Form ändert, erfolgt ein Hochzählen im Major/Minor-Bereich (wobei das nicht zwingend zu Dateninkompatibilitäten führen muss). Die Release-Nummer war also für Fehlerbehebungen und kosmetische Anpassungen reserviert. Insbesondere erhielt jede freigegebene Version (eben jedes Release) eine eigene Release-Nummer. Mit den Kunden wurden dann auch entsprechend nur diese drei Werte kommuniziert. Die Build-Nummer wurde mit jedem (automatischen) Build erhöht und diente als Referenz für die Qualitätssicherung.

Soweit, so gut. Kommen wir aber nun zum Rücksetzen dieser Werte (und hier bin ich gespannt auf eure Beiträge): Während die Major-Version wohl eher selten auf 0 gesetzt wird, habe ich die Minor- und Release-Version immer bei der Erhöhung einer der höheren Nummern auf 0 gesetzt. Die Build-Version sollte nach diesem Schema eigentlich auch immer bei einer Erhöhung der Release-Version auf 0 gesetzt werden, allerdings bin ich hier von diesem Schema abgewichen. Die Build-Version wird kontinuierlich erhöht, weil so die Kommunikation mit den Testern einfacher war.

Nun hatte es sich irgendwie so ergeben, daß die Build-Nummer bei einem Wechsel der Major/Minor-Nummern doch auf 0 gesetzt wurde, da das Build-System sonst durcheinander gekommen wäre. Ausgelöst wurde das durch Maintenance-Releases für ältere Versionen (Major/Minor), wenn schon neuere Versionen (Major/Minor) freigegeben waren. Im Ergebnis kommt so also eine Art Hybrid-Nummerierung raus, die eigentlich keinem rechten Schema folgt. Irgendwie bin ich damit nicht ganz zufrieden. Deshalb dieser (zugegeben etwas längliche) Beitrag. Wie handhabt ihr das?

Gleich vorweg: Die Subversion-Revisionsnummer steht hier nicht zur Verfügung.

Nächster Knackpunkt war mein erstes Projekt für OSX. Dort gibt es nur drei statt vier Nummern und das obige Schema lässt sich dort nicht so einfach übernehmen. Ich weiß, daß da noch nicht allzu viele Erfahrungen vorhanden sein werden, aber vielleicht hat ja doch jemand eine pfiffige Idee.

[himitsu]

Auch in Windows kann man die Version anders interpretieren:

Vaaa.bbb.ccc.ddd -> $aabbccdd -> v255.255.255.255

Vaaa.bbb.ccccc -> $aabbcccc -> v255.255.65535

Zumindestens hab ich das schon paar mal gesehn.


Ich selber vergess ständig das Build hochzuzählen, also im Prinzip kann ich es auch vergessen und würde es z.B. für eine Repository-Nummer verwenden, aber das geht eh nur beim zweiten Schema, da man sonst ab 255 plötzlich Probleme bekommt.


Ich glaub das Versionsschema von meinem Manifest-Creator werde ich weiterhin beibehalten.

Major.Minor.Patch und im Programm wird es nur als vM.N angezeigt:
1.2.0.x -> v1.2
1.2.1.x -> v1.2b
1.2.3.x -> v1.2d
1.3.0.x -> v1.3

Wenn man die letzte Stelle einfach ignoriert, dann hast du praktisch das selbe Format wie beim OSX,
wobei ich aber nicht weiß, wie da die Grenzen für die einzelnen werte liegen, aber bis 255 sollten die auch mindestens gehen und ich hoffe mal das reicht.

[Lemmy]

Zitat:

Zitat von himitsu (Beitrag 1236595)

Ich selber vergess ständig das Build hochzuzählen, also im Prinzip kann ich es auch vergessen und würde es z.B. für eine Repository-Nummer verwenden, aber das geht eh nur beim zweiten Schema, da man sonst ab 255 plötzlich Probleme bekommt.

dann erzähl da mal bitte mehr darüber. Selbst Delphi 7 auf Windows XP SP 3 kann die Versionsnummer 1.3090.2134.32767 erzeugen und Windows zeigt die brav an...
Außerdem macht es Microsoft ja vor:
ntdll.dll: Version 5.1.2600.6055

Oder gelten die 255 für MaxOS?

Grüße

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1236595)

Ich selber vergess ständig das Build hochzuzählen, also im Prinzip kann ich es auch vergessen und würde es z.B. für eine Repository-Nummer verwenden, aber das geht eh nur beim zweiten Schema, da man sonst ab 255 plötzlich Probleme bekommt.

Die einzelnen Nummern sind als Word gespeichert. Das reicht also bis 65535. (Danke, Lemmy!)

Zitat:

Zitat von himitsu (Beitrag 1236595)

Wenn man die letzte Stelle einfach ignoriert, dann hast du praktisch das selbe Format wie beim OSX,
wobei ich aber nicht weiß, wie da die Grenzen für die einzelnen werte liegen, aber bis 255 sollten die auch mindestens gehen und ich hoffe mal das reicht.

Die OSX Entwickler Doku spricht einfach nur von Integer - was immer das bei denen heißt.

Bei Major/Minor kommt man wohl mit 255 hin, wenn man nicht die Jahreszahl als Major verwenden möchte, aber bei Release und insbesondere Build wäre mir das zu wenig. Wenn OSX aber wenigstens die 65535 erlaubt, wäre ich ja zufrieden.

Die Idee mit dem weglassen ist gar nicht so dumm. Ich würde aber dann eher die Major/Minor auf eine Zahl reduzieren. Ist vielleicht kein schlechter Ansatz und kickt vor allem die Politik aus dem ganzen System raus. Leider passt dann die Nomenklatur nicht mehr so richtig.

[Phoenix]

Zitat:

Zitat von Uwe Raabe (Beitrag 1236591)

Gleich vorweg: Die Subversion-Revisionsnummer steht hier nicht zur Verfügung.

Das ist schade. Das nehme ich immer für die letzte Stelle (oder den Git-Hash ;-) ).

Ich halte mich bei unseren Versionen immer an "Semantic Versioning": http://semver.org/
Das definiert die ersten drei Stellen. Die vierte würde ich tatsächlich immer hochzählen, oder aber den Build-Zeitpunkt reinkodieren.
Wenn man das macht, z.B. Unix-Timestamp als Basis, Genauigkeit auf Datum + Uhrzeit), so hat man den Build auch eindeutig identifiziert (für Testing und Bugmeldungen interessant) und man kann den Stand zum Zeitpunkt X auch jederzeit wieder auschecken und das Problem nachvollziehen.

[Uwe Raabe]

Zitat:

Zitat von Phoenix (Beitrag 1236602)

Zitat:

Zitat von Uwe Raabe (Beitrag 1236591)

Gleich vorweg: Die Subversion-Revisionsnummer steht hier nicht zur Verfügung.

Das ist schade. Das nehme ich immer für die letzte Stelle (oder den Git-Hash ;-) ).

Ich halte mich bei unseren Versionen immer an "Semantic Versioning": http://semver.org/
Das definiert die ersten drei Stellen. Die vierte würde ich tatsächlich immer hochzählen, oder aber den Build-Zeitpunkt reinkodieren.
Wenn man das macht, z.B. Unix-Timestamp als Basis, Genauigkeit auf Datum + Uhrzeit), so hat man den Build auch eindeutig identifiziert (für Testing und Bugmeldungen interessant) und man kann den Stand zum Zeitpunkt X auch jederzeit wieder auschecken und das Problem nachvollziehen.

Das Build eindeutig zu kennzeichnen ist genau die Absicht, die ich mit der Build-Nummer verfolge. Ich möchte das aber nicht von einem Versionskontrollsystem abhängig machen. Nach diversen Systemen angefangen (bei RCS angefangen) bin ich dann letztlich vor ein paar Jahren von Subversion auf Mercurial umgestiegen. Ich weiß aber halt nicht, was die Zukunft noch so bringt. Anfangs habe ich mein Versionsnummernsystem noch dem VCS angepasst (zweimal). Das ist, wenn ich hier mal Müntefering zitieren darf, Mist.

Es wäre allerdings auch wünschenswert, wenn die Build-Nummern aufsteigend sind (nicht notwendigerweise lückenlos). Sonst muss man immer erst irgendwo nachsehen, welches neuer ist.

[BUG]

Zitat:

Zitat von Uwe Raabe (Beitrag 1236604)

Es wäre allerdings auch wünschenswert, wenn die Build-Nummern aufsteigend sind (nicht notwendigerweise lückenlos). Sonst muss man immer erst irgendwo nachsehen, welches neuer ist.

Das würdest du mit dem einfachem Hochzählen der Buildnummer (oder Timestamps) erreichen.
Das einzige Problem ist dann nur, dass man nicht mehr sagen kann: "Ab Build 1337 bis 4711 ist es das Release 1.3.7." Das sollte zu verkraften sein.

[Uwe Raabe]

Zitat:

Zitat von BUG (Beitrag 1236606)

Zitat:

Zitat von Uwe Raabe (Beitrag 1236604)

Es wäre allerdings auch wünschenswert, wenn die Build-Nummern aufsteigend sind (nicht notwendigerweise lückenlos). Sonst muss man immer erst irgendwo nachsehen, welches neuer ist.

Das würdest du mit dem einfachem Hochzählen der Buildnummer (oder Timestamps) erreichen.
Das einzige Problem ist dann nur, dass man nicht mehr sagen kann: Ab Build 1337 bis 4711 ist es das Release 1.3.7. Das sollte zu verkraften sein.

Ja, das wäre vollkommen OK.

Bei Timestamps bin ich mir nicht sicher, ob der Zahlenraum ausreicht. Es gibt Zeiten, da kommen die Builds im 5 Minutentakt - dann ist wieder wochenlang nichts.

[musicman56]

Hallo,

ich hatte früher auch immer wieder Probleme mit der Versionsverwaltung. Vor allem wenn dann mal ein Programm schon 10+ Jahre auf dem Markt ist, und Kunden dazu noch anfragen. Geärgert hat mich auch, dass aus der Versions-Nummer kein Rückschluss auf das Ausgabejahr möglich war.

Im Dezember 2011, als ich wieder mal ein Jahresupdate für 2012 rausgab, hab ich einen totalen Schnitt zum alten System gemacht, der sich bisher auch sehr gut bewährt hat.

Hauptversion: 20
Nebenversion: das Ausgabejahr also 12, 13 usw.
Ausgabe: eine 1 und dann das Monat und den Tag, beides immer zweistellig, bsp. für heute 11119
Build: Wird bei jeder Ausgabe manuell hochgezählt

Zusätzlich bab ich dann noch einen neuen Schlüssel "Ausgabedatum" angelegt, den ich mit dem Datum der Compilierung belege.

Eine fertige Exe bekommt dann als Datum das "Ausgabedatum" und als Zeit die Haupt- und Neben-Versionsnummer. Heute wäre das dann 19.11.2013 20:13.00.

Für das Setzen der Dateizeit (wobei ich hier immer alle 3 Datum's ändere) lese ich wiederum den Schlüssel "Ausgabedatum" aus der fertigen Exe aus und habe somit eine zusätzliche Kontrolle, dass das Dateidatum mit dem "Ausgabedatum" übereinstimmt, und ich somit das Setzen des Ausgabedatums nicht vergessen habe. Oder später, ob jemand die Exe manipuliert hat.

Damit es bei der Sommerzeit-Umstellung keinen Stress gibt, helfe ich ein bischen nach mit

Delphi-Quellcode:

  DateTimeToSystemTime()
  SystemTimeToFileTime()
  LocalFileTimeToFileTime();
end;

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1236598)

Die einzelnen Nummern sind als Word gespeichert. Das reicht also bis 65535. (Danke, Lemmy!)

Mist, stimmt, das waren ja zwei Longwords und nicht nur Einer ... OK, dann hat man mehr Platz.

Delphi-Quellcode:

  TVersion = record
    case Integer of
      0: (VersionMS, VersionLS:   LongWord);
      1: (Minor,        Major:        Word;
          Build,        Patch:        Word);
      2: (MinorRelease, MajorRelease: Word;
          BuildNumber,  PatchLevel:   Word);
  end;

[Union]

Ich verwende keine (automatische) Build-Nummer. Ich zähle die manuell hoch, bei jeder Veröffentlichung (auch Testversionen). Dabei verwende ich nur 1 Stelle, so dass ein Überlauf in die nächsthöhere Stelle erfolgt und ein enstprechendes Setzen auf Null. Die Folge ist, dass es Lücken im Produktiveinsatz bei den Buildnummern gibt (also an der letzten Stelle).

Ich verwende auch eine "dynastische" Versionsvergabe, wenn es mal einen umfangreichen Sprung gab. Dies aber bloß als Zusatz, damit sich die User das leichter merken können. Dafür Suche ich mir für jedes Programm oder Paket etwas entsprechendes aus (Pharaonen, griechische Götter etc.). Das wird ja seit Jahrzehnten z.b. bei Intel (aber meist mit Städte- oder Regionsnamen) gemacht. Android verwendet Süßigkeiten ;)

Ergebnis ist dann sowas wie "1.9.2.7 (Hephaistos)"

[generic]

Was Versionsnummern betrift gibt es einen quasi Standard.
Semantic Versioning

Meine Arbeitsweise:
a.b.c

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Ich führe in jedem Teil eine Versionsnummer mit, da ich alles als getrenntes Projekt betrachte - also
1) Programm-Version
2) Datei-Version
3) Datenbank-Version

Aus Sicht des Programms/Clients gibt es dann ein Kompatibilitätsbereiche - Client weiß womit er kann. Datenbank zu alt - Client zu alt etc.
Ich führe Datenbankskripte welche jeweils zu nächsten Version migrieren können. Diese werden allerdings nicht automatisch ausgeführt.

Meine Dateien basieren meist auf XML mit Schema. Falls es ein neues Dateiformat gibt, konvertiere ich diese via XSD - allerdings nur für den Upgrade-Pfad auf die nächste höhere Version. Unter Umständen werden dann mehrere Upgrades ausgeführt, wenn eine Datei geöffnet wird.

Durch die XSDs und die Versionsnnummern kann ein Client dann sehr gut eingrenzen mit welchen Dateiversionen er kann und welche nicht.

[RWarnecke]

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

[generic]

Zitat:

Zitat von RWarnecke (Beitrag 1236773)

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

Ich zähle jede Roadmap welche Bugs oder Features zusammenfasst bzw. ein MSI welches hinten herausfällt.

[Sherlock]

Zitat:

Zitat von generic (Beitrag 1236905)

Zitat:

Zitat von RWarnecke (Beitrag 1236773)

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

Ich zähle jede Roadmap welche Bugs oder Features zusammenfasst bzw. ein MSI welches hinten herausfällt.

Jupp, genau so machen wir es auch. Der Buildcount an vierter Stelle wird nur benötigt, um unterschiedliche Testdurchläufe unterscheiden zu können, und wird mit jeder Änderung an den ersten drei Stellen auf 0 zurück gesetzt.

Sherlock

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1236907)

Jupp, genau so machen wir es auch. Der Buildcount an vierter Stelle wird nur benötigt, um unterschiedliche Testdurchläufe unterscheiden zu können, und wird mit jeder Änderung an den ersten drei Stellen auf 0 zurück gesetzt.

Ich hatte das mal versucht von Anfang an unterbrechungsfrei fortlaufend hochzuzählen, um zur Versionsnummer eine quantitative Zählung mitzunehmen.
So wie die Revision bei den Delphi/RAD-Versionen.

D7 7.0.8.1 / 7.0 (Build 4453) => Major.Minor Build (Dateiversion / Programmversion)
XE 15.0.3953.35171 => Major.Minor.Revision.Build
XE2 16.0.4429.46931
XE3 17.0.4625.53395
XE3 17.0.4770.56661 (Update 2)
XE4 18.0.4905.60485
XE5 19.0.13856.4978 => Major.Minor.xxx.Revision ???

k.A. wo z.B. die Delphi-Updates ersichtlich sind, außer in "Installierte Aktualisierungen" und in Revision/Build



Dank einer fortlaufenden Revision/Build hätte man für die Versionsnummern von einzelnen Modulen/Versionszweigen noch die Info, wievielte Version das wirklich ist
und kann so das Major+Minor in gemeinsammen Schritten über das gesamte Projekt zählen, jenachdem wann das jeweilige Modul zuletzt aktualisiert wurde.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1236912)

Ich hatte das mal versucht von Anfang an unterbrechungsfrei fortlaufend hochzuzählen, um zur Versionsnummer eine quantitative Zählung mitzunehmen.

Ja, das war eigentlich auch mein Ziel. Es ist intern einfach effizienter mit nur einer einzigen Zahl zu kommunizieren. Aber es ist halt etwas schwierig, dem Build-System diese zentrale Zahlenvergabe beizubringen, wenn man unterschiedliche Revisions-Branches hat und zusätzlich noch mit Distributed Builds arbeiten möchte. Ich habe da gerade Continua am Wickel, bin aber noch nicht so richtig überzeugt.

Zitat:

Zitat von himitsu (Beitrag 1236912)

XE3 17.0.4625.53395
XE5 19.0.13856.4978 => Major.Minor.xxx.Revision ???

Ergänzend:

XE3 17.0.4770.56661 (Update 2)
XE4 18.0.4905.60485

Da ist dann irgendwann wohl das Word für die Build-Nummer übergelaufen, was zu einem wie auch immer gearteten Sprung (ca. 8000 oder $2000) in der Revision geführt hat.

[Sherlock]

IMHO erlaubt die Buildnummer keine zuverlässigen Aussagen, vor allem wenn im Team entwickelt wird. Sie ist einzig eine tolle Zahl, die irgendwie immer größer werden könnte.
Es gibt nur die Methode zu einem Release alle vier Stellen zu dokumentieren (in Release Notes oä), um wirklich zu wissen, was wann tatsächlich raus gegangen ist.
Effizienz in der Kommunikation kann ich bei Buildnummern jenseits der 20 ohnehin nicht erkennen, da sind Zahlendreher und sonstige Missverständnisse deutlich öfter zu erwarten als wenn man schlicht von einer Version "Drei Sieben Fünf Zwo" spricht.
Verdeutlichung: "Drei Sieben Fünf Zwo" vs "Drei Sieben Fünf eintausenvierhundertfünfundzwanzig" oder meinetwegen auch "Drei Sieben Fünf Eins Vier Fünf Zwo Null"
Die vierte Stelle kann zu nichts dienen, ausser zum (pardon my french) Schwanzvergleich ;)

Sherlock

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1236928)

Die vierte Stelle kann zu nichts dienen, ausser zum (pardon my french) Schwanzvergleich ;)

Nja, bisher führe ich die 4. Stelle noch mit (wenn ich sie nicht vergesse hochzusetzen), aber im Programm (z.B. Info-Dialog) wird sie eh nicht mit angezeigt.
> sie Manifest-Creator > da gibt es nur Major+Minor und ein Patch größer 0 wird als Buchstabe angehängt.