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;