Tokyo Update 3 identifizieren

[Ralf Kaiser]

Halli Hallo,

Gibt es eigentlich eine Möglichkeit irgendwie per IFDEF festzustellen ob von Delphi Tokyo das Update 2 oder schon das Update 3 installiert ist? Ich habe bisher keine unterschiedlichen DEFINES für diese 2 Versionen gefunden aber das Update 3 führt einige neue Klassen ein, weshalb auf Arbeitsplätzen die nur Update 2 installiert haben das kompilieren fehlschlagen würde.

Danke schon mal,
Ralf

[KodeZwerg]

Compiler-Versionen
Leider ist "VER320" für "Delphi 10.2 Tokyo / C++Builder 10.2 Tokyo" das letzte.

edit
Vielleicht über die RTL Value?

[mkinzler]

Der Compiler ist ja auch der selbe. Besser wäre es nach der Version der RTL oder der UI-Bibliothek zu entscheiden.

Die RTLVersion von Tokyo Update 3 ist 32. Bin mir aber nicht sicher ob diese nicht auch die Version der Vorgänger 10.2er war.

[himitsu]

Im Prinzip müssten die Updates eine eigene Versionsnummer bekommen, da man ja seit 'ner Weile die "Updates" nicht mehr für Bugfixes, sondern auch für neue Features (Upgrades) nutzt.

VER320 = 10.2
VER321 = 10.2.2
VER322 = 10.2.3
...


Bleibt nur noch, dass du nicht nur auf Versionsnummer, sondern auf das Vorhandensein/Nichtvorhandensein von Funkionen/Klassen/Typen/Variablen/Konstanten prüfst, welche sich bei dem Update geändert hatten.

Aber prinzipiell ist es eh besser auf Features zu prüfen, anstatt auf Versionen.


RTLVersion und VCLVersion gibt es theoretisch, aber die waren bis jetzt immer identisch mit der CompilerVersion.
FMXVersion und Versionen für andere Programmteile gibt es garnicht.

[Ralf Kaiser]

Zumindest in der Tabelle die im DocWiki die ganzen Versionen auflistet wird nicht zwischen Update 2 und Update 3 unterschieden. :cry:

[mkinzler]

Als Konstante: FMX.Types.FireMonkeyVersion

[Uwe Raabe]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401535)

das Update 3 führt einige neue Klassen ein, weshalb auf Arbeitsplätzen die nur Update 2 installiert haben das kompilieren fehlschlagen würde.

Du kannst das Vorhandensein dieser Klassen mittels

Delphi-Quellcode:

{$IF Declared(TMyNewCLass)}

prüfen.

[Ralf Kaiser]

Zitat:

Zitat von himitsu (Beitrag 1401540)

Aber prinzipiell ist es eh besser auf Features zu prüfen, anstatt auf Versionen.

Na ja, es geht hier speziell um die Unit System.Net.Mime

Da gibt es (Update 2) einmal die Liste aller Mimetypes als Array in einer Konstanten. In Update 3 gibt es dieses Array nicht mehr, dafür existiert eine Klasse TMimeTypes die diese Daten als Dictionary verwaltet.

Ich habe keinen Schimmer, wie ich diese beiden Versionen beim kompilieren über IFDEF oder so auseinander halten soll.

Die einzige Idee die ich habe ist es die neuere Unit erst einmal lokal in das Projektverzeichnis zu kopieren und ins Projekt aufzunehmen. So würden auch ältere Compiler die neue Unit verwenden (ich mag diese Lösung aber gar nicht...)

[himitsu]

Wie schon erwähnt, siehe der Post über dir.

Delphi-Quellcode:

{$IF Declared(TMimeTypes)}

{$IF Defined(VER320) and Declared(TMimeTypes)}

{$IF (CompilerVersion >= 32.0) and Declared(TMimeTypes)}

1 und 3 sind von der Bedingung her zukunftssicherer.

Zitat:

FireMonkeyVersion

Wer kommt denn darauf.

Hatte vor 2-3 Jahren mal gesucht, aber nichts gefunden.


Oder Emba führt endlich mal die Versionen besser. z.B.:
VER320 und VER323 und CompilerVersion=32.3 für ein Update.

[Stevie]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401535)

auf Arbeitsplätzen die nur Update 2 installiert haben

Gibt es einen triftigen Grund, das so zu belassen? Imho sollte man alle Arbeitsplätze auf das neuste Update ziehen.

[dummzeuch]

Zitat:

Zitat von Stevie (Beitrag 1401548)

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401535)

auf Arbeitsplätzen die nur Update 2 installiert haben

Gibt es einen triftigen Grund, das so zu belassen? Imho sollte man alle Arbeitsplätze auf das neuste Update ziehen.

Wenn man Software ausgeliefert hat, die mit der alten Version compiliert wurde, sollte man zumindest eine Installation davon behalten, um ggf. einen "kleinen" Bugfix ausliefern zu können, ohne dass man gleich das ganze Programm neu testen muss. Wenn schon nicht wegen des "gesunden Menschenverstandens", dann wenigstens wegen der Qualitätssicherung (insbesondere dann, wenn die fremdbestimmt ist, z.B. von der amerikanischen FDA).

[Ralf Kaiser]

Zitat:

Zitat von dummzeuch (Beitrag 1401571)

Zitat:

Zitat von Stevie (Beitrag 1401548)

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401535)

auf Arbeitsplätzen die nur Update 2 installiert haben

Gibt es einen triftigen Grund, das so zu belassen? Imho sollte man alle Arbeitsplätze auf das neuste Update ziehen.

Wenn man Software ausgeliefert hat, die mit der alten Version compiliert wurde, sollte man zumindest eine Installation davon behalten, um ggf. einen "kleinen" Bugfix ausliefern zu können, ohne dass man gleich das ganze Programm neu testen muss. Wenn schon nicht wegen des "gesunden Menschenverstandens", dann wenigstens wegen der Qualitätssicherung (insbesondere dann, wenn die fremdbestimmt ist, z.B. von der amerikanischen FDA).

Na, das hört sich ja wirklich vernünftig als Grund an. Aber leider ist es oft ein einfaches "Neue Version installieren? - Hab ich keine Zeit..." :-(

[Ralf Kaiser]

Zitat:

Zitat von Uwe Raabe (Beitrag 1401543)

Du kannst das Vorhandensein dieser Klassen mittels

Delphi-Quellcode:

{$IF Declared(TMyNewCLass)}

prüfen.

Das war natürlich, wie immer, der entscheidende Tipp. Vielen Dank!

[Stevie]

Zitat:

Zitat von dummzeuch (Beitrag 1401571)

Zitat:

Zitat von Stevie (Beitrag 1401548)

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401535)

auf Arbeitsplätzen die nur Update 2 installiert haben

Gibt es einen triftigen Grund, das so zu belassen? Imho sollte man alle Arbeitsplätze auf das neuste Update ziehen.

Wenn man Software ausgeliefert hat, die mit der alten Version compiliert wurde, sollte man zumindest eine Installation davon behalten, um ggf. einen "kleinen" Bugfix ausliefern zu können, ohne dass man gleich das ganze Programm neu testen muss. Wenn schon nicht wegen des "gesunden Menschenverstandens", dann wenigstens wegen der Qualitätssicherung (insbesondere dann, wenn die fremdbestimmt ist, z.B. von der amerikanischen FDA).

Dafür hat man CI und nicht einen Arbeitsplatzrechner.

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401575)

Na, das hört sich ja wirklich vernünftig als Grund an. Aber leider ist es oft ein einfaches "Neue Version installieren? - Hab ich keine Zeit..." :-(

Meine Erfahrung sagt mir, dass man manchmal mehr Zeit mit damit verbringt, Workarounds zu schaffen oder Bugs sucht, die aus einer inhomogenen Umgebung entstehen.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1401722)

Dafür hat man CI und nicht einen Arbeitsplatzrechner.

:thumb:

Zitat:

Zitat von Ralf Kaiser (Beitrag 1401575)

Meine Erfahrung sagt mir, dass man manchmal mehr Zeit mit damit verbringt, Workarounds zu schaffen oder Bugs sucht, die aus einer inhomogenen Umgebung entstehen.

Ich erinnere mich noch an den Fall als einer der Kollegen das letzte ADO/Variant-Update von D6 nicht installiert hatte und wir auf suche nach Speicherlücken gingen die wir nicht nachstellen konnten ...
Bis uns dann die Idee kam nachzufragen wer denn diese Exe compiliert hatte.
Und CI ging damals nicht. Der Build unter Jenkins mit der D6-Exe hatte immer defekte Exe produziert ...

[KodeZwerg]

Könnte man eventuell das Update 3 mittels der ProjectVersion Angabe in der .dproj Datei ermitteln?
Bei Tokyo 10.2.3 steht da eine 18.4 eingetragen.

edit
neues Wissen
Delphi 10.2 Tokyo hat 18.2 da eingetragen, also könnte das ein guter Ansatz sein.

[Ralf Kaiser]

Zitat:

Zitat von KodeZwerg (Beitrag 1401900)

Könnte man eventuell das Update 3 mittels der ProjectVersion Angabe in der .dproj Datei ermitteln?
Bei Tokyo 10.2.3 steht da eine 18.4 eingetragen.

edit
neues Wissen
Delphi 10.2 Tokyo hat 18.2 da eingetragen, also könnte das ein guter Ansatz sein.

Beim kompilieren? Ich will nicht selbst überprüfen, welches Update gerade installiert ist, das weiß ich nämlich, ich weiß sogar wer im Team welche Version installiert hat.

Es ging darum beim kompilieren zu unterscheiden welche Version aktuell vorliegt, z.B per IFDEF und das geht mit dem Vorschlag von Stevie sehr gut.

[himitsu]

nur Stevie?

:cry:

[KodeZwerg]

Kann man die ProjectVersion Angabe also gar nicht auswerten? Das ist ja blöd, falls es Überhaupt der Richtige Weg gewesen wäre.

[himitsu]

Nicht im Quellcode (IFDEF und Co.), aber den Quellcode interessiert es ja eigentlich auch nicht wie die IDE das Projekt verwaltet/speichert.

Das Problem ist einfach, dass die Updates nicht mehr in der CompilerVersion enthalten sind.



VERxxx und CompilerVerison (IMHO sollten hier auch alle Updates und besser auch Hotfixes gezählt werden)
RTLVersion (und dieses Problem hier würde auf jene Version gehen, aber ich hab noch nie erlebt, dass sie sich von der CompilerVersion unterscheiden)
VCLVersion
FireMonkeyVersion

[Ralf Kaiser]

Zitat:

Zitat von himitsu (Beitrag 1401907)

nur Stevie?

:cry:

Sorry, Schande über mich... Ich meinte natürlich vor allem auch Uwe!