Versionsnummern bei mehreren Versionszweigen

[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 von himitsu:

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 von himitsu:

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 von himitsu:

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.

[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 von Uwe Raabe:

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)"