Programmversionierung

[Mirco]

Hallo Leute,

mich stört an unserem Programm noch eine Sache: Die "Version".

Wie regelt ihr das bei euch? Wie man jetzt die Versionsnummer aufbaut, ist ja jedem selber überlassen, ich finde nur wichtig, dass mit jedem offiziellen Build die Versionsnummer erhört wird.

Version 1.1.0.0 --> neu kompiliert und ausgeliefert --> Version 1.1.0.1.

Je nach Größe der Änderungen können die Sprünge ja größer und kleiner Ausfallen.

Wie regelt man das am Besten in XBase? Muss ich was in der Project.xpj einstellen, damit die Version auch in der .exe steht? Nutzt ihr dafür Build-Scripts oder so?

Grüße aus Wesel

Mirco

[Jan]

Mirco,

das kommt in die .arc rein, die Du für die Anzeige der Themes ja ohnehin hast. Das sieht dann z. B. so aus:

Code: Alles auswählen

VERSION
"CompanyName"      = "Mircos Codewerkstatt"
"FileDescription"  = "Das Superprogramm"
"ProductName"      = "Superprogramm"
"FileVersion"      = "1.1.0.1"
"ProductVersion"   = "1.0"
"LegalCopyright"   = "Copyright © Mirco 2011"
"OriginalFilename" = "Super.exe"

Jan

[brandelh]

Ich zähle "Hauptversion.Unterversion.Build" in einem eigenen String, die Resource FileVersion zähle ich einfach hinten hoch,
wobei ich im Programm selbst noch einen String verwende und beides aus eine CH Datei lade.
Das ist aber nur weil es früher nicht möglich bzw. fehlerhaft war. Seit der 1.90 (oder früher ?) sollte LoadResource() die Produktversion sauber lesen können.

Ich mache das so ...

Die Hauptversion wird nur bei wirklich vielen bzw. deutlichen Änderungen benutzt.
Die Unterversion nutze ich normalerweise um kleinere Änderungen zu kennzeichnen, dann wird die "Build" wieder auf 000 gesetzt.
Die Build wird bei jeder neuen EXE hochgezählt, wenn ich nur Fehler verbessert habe, aber keine neuen Eigenschaften enthalten sind.

[Mirco]

Jap, so mache ich es wahrscheinlich auch. Version ist ja 4 "stellig", also 0.0.0.0.

Die ersten beiden Nummern sind für bedeutende Änderungen, die erste für wirklich neue Hauptversionen, die zweite für größere Änderungen / Neuerungen. Diese beiden werden sehr selten geändert.

Hauptsächlich wird die dritte Stelle geändert (größere Fehlerbehebung, etc.) bzw. die letzte, jedes OFFIZIELLE Build. Zum testen erstellt man ja schon häufiger ne Version .

[Manfred]

Versionsnummer sind doch Schall und Rauch.

Ich habe mir mittlerweile angewöhnt alle Module mit einem Datumsstring zu versehen (XX.XX.XXXX). Das Main bekommt jedesmal ein neues Datum wenn irgendwas irgendwo geändert wurde und das jeweilige Modul dann auch. So weiß man ganz genau, was überhaupt wann geändert wurde. Und Versionsnummerkasperei? Man sieht es ja jetzt mit FF und TB. Alle naselang eine neue Ziffer vor dem Punkt. Was hat man davon? Nichts. Versionsnummern sollten m.E. nur dazu dienen die einzelnen Varianten auseinanderhalten zu können. Mehr nicht. Und da reicht eben das komplette Datum. Hat den Vorteil, jeder sieht direkt, wie alt etwas ist. Außer man möchte das verhindern.

[brandelh]

Hallo Manfred,

PS: schau dir mal die Seite mit __DATE__ __FILE__ __TIME__ in der Hilfe an, wobei das immer das compilierdatum ist ( "Vordefinierte Konstanten des Compilers" oder suchen nach __date__ )

dann kannst für dich also mit einem einfachen Kompilerlauf das Programm auf einen völlig neue Version bringen

... der Enduser kann aber leichter 10.00.001 mit 9.00.002 unterscheiden als 25.02.2011 ... insbesondere wenn auch Amerikaner das Programm sehen

[georg]

Hallo,


bei mir gibt es ein Modul, history.prg, in dem in mehreren Arrays (es gab da mal eine Grössenbeschränkung für die Initialisierung) {Version, Datum, Änderungsgrund} drinsteht.

Beim Programmstart wird die erste Routine aufgerufen, welche ein Array aus den mehreren erstellt und nach Versionsnummer sortiert. Dann wird die Versionsnummer zurückgegeben und in den Title-Bar angezeigt.

Eine weitere Funktion in history.prg erlaubt es, die Versionen top-down (d.h. neueste oben) anzuzeigen.

Es ist halt nur die Disziplin erforderlich, die Versionsführung jedesmal festzuhalten.


Gruss,

Georg

[Herbert]

4-stellig ist Standard. Die manifest-Datei zeigt dies auch so auf.

die erste Ziffer ist die Version (wie wir alle nutzen - ohne Manfred )
Ich ändere die Version nur bei grossen Aenderungen. Diese Versionen muss ein Kunde bezahlen, selbst wenn er einen Supportvertrag hat.
die zweite Ziffer ist die Unterversion
Kleinere Anpassungen entstanden aus Kundenwünschen und eigenen neuen Erkenntnissen (z.B. aus dem Forum hier)
die dritte Ziffer ist die Generation
Hier werden einzig Bugfixes eingebaut
die vierte Ziffer ist für Aenderungen in den Umgebungswerten (neue Basisdateien, Registryweerte usw.)

Ich brauche nur deren drei, wobei ich die dritte Stelle in Buchstaben einsetze: z.B. Version 7.4.b

[urbi]

ich hänge zusätzlich noch das Conpilierdatum an die EXE
und lese beim Programmstart die lezten 8 Bytes aus.

Code: Alles auswählen

PROCEDURE MAIN(exFile)
LOCAL handle,control
exFile:=IIF(EMPTY(exFile),"urbi.exe",exfile)
SETFATTR(exFile,32)
HANDLE := FOPEN(exFile,2)
FSEEK(handle,-12,2)
CONTROL := FREADSTR(handle,12)
IF !LEFT(control,4)=="####"
   FSEEK(handle,0,2)
   control := "####"+Str(Year( Date() ), 4 )+"."+STRZERO(DOY(DATE()),3)+DTOC(DATE())
   FWRITE(handle,control)
ENDIF
FCLOSE(handle)
RETURN 

PROCEDURE APPSYS
RETURN 

Gruß
Rainer

[Herbert]

Der Exe stets einen anderen Namen zu geben ist nicht empfehlenswert (Programmverknüpfungen usw.), insbesondere wenn der Zugriff auf die Workstation nur mittels Admin-Rechten, die man beantragen muss, erfolgen können.
Was bezweckst du damit?
Die Version ist doch innerhalb der .EXE auffindbar (schon nur wegen des Info-Fensters).

[Koverhage]

Ich mache das so

function progversion()
return "5.99.227"

Wenn der Kunde ein Update bekommt, muss ich eh alles neu compilieren.

[Mirco]

Ich mache das so

function progversion()
return "5.99.227"

Wenn der Kunde ein Update bekommt, muss ich eh alles neu compilieren.

Da hast du nur das Problem, dass deine Exe selber (unter Eigenschaften) die Version nicht richtig anzeigt.