Der ein oder andere hat sich nach der Erstellung einer neuen Version eines bestehenden Paketes gewundert, warum dies auf Computern auf denen die Vorgängerversion bereits installiert ist, nicht installiert wird. Dazu gibt es eine Erklärung warum es so ist, wie es ist und wie man dieses Problem ggf. umgehen kann.

Der Blog wird „alt“ – Neuerung seit Empirum v14.2

Vergleich der Versionsnummer: Ist die Version im Abschnitt [Setup] der Setup.inf GRÖSSER GLEICH 14.2 gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt bis zum nächsten Punkt als komplette Zahl verglichen (45 kleiner 100). Daher ist die Version 1.100 höherwertiger als die Version 1.45 .

Ist die Version im Abschnitt [Setup] der Setup.inf KLEINER 14.2 (z.B. 10.5) gilt folgendes Verhalten: Die Versionsnummer wird nach dem ersten Punkt Spaltenweise verglichen. Daher ist die Version 1.45 höherwertiger als die Version 1.100. Die Zahlen nach dem ersten Punkt werden nicht als eine Zahl verglichen (45 kleiner 100), sondern Zahlenweise (4 ist größer 1 und 5 ist größer 0). Da die erste Zahl 4 nach dem Punkt bereits größer als die Zahl 1 ist, wird nicht geprüft.

Quelle: Matrix42 Online Hilfe

Ab hier folgt nun die Erläuterung zu [Setup] Version=10.5 …

Martin Niemann hat dies sehr anschaulich und ausführlich auf seinem Blog erläutert. Beim Treffen auf dem vor wenigen Tagen stattgefundenen Matrix42 CustomerDay habe ich in darauf angesprochen, ob ich seinen Eintrag samt Quellenverweis hierher übernehmen darf. Vielen Dank Martin für Deine Erlaubnis!

So hier nun die Erläuterung:

Fast ein jeder wunderte sich schon, wieso die neue Version 4.10 des Paketes von Empirum nicht als höherwertig identifiziert wurde, als das alte 4.9er Paket – „die Zehn ich doch höher als die Neun!“

Hierzu muss man wissen, das in Empirum nur die Zahl vor dem ersten Punkt als ganze Zahl verstanden wird. Alle Werte danach werden Ziffer für Ziffer verglichen.

Hier eine Liste von Versionsnummer in absteigender Reihenfolge:

12	.	1	0	.	0	0	.	0	0
9	.	5	0	.	0	0	.	0	0
3	.	9	0	.	0	0	.	0	0
3	.	1	0	.	0	0	.	0	0
1	.	1	0	.	0	1	.	0	0
1	.	1	0	.	0	0	.	0	3

Die grauen Zahlen zeigen, wie man sich beim Vergleichen von Versionsnummern diese Vorstellen sollte. Vergleicht man nun eine 3.10 mit einer 3.90, ist die 3.9 selbstverständlich höher als die 3.10.

Um zukünftig nicht an die Grenzen der Versionierung zu stoßen, empfiehlt es sich die Versionsnummern nach einem einheitlichen Schema zu erstellen: Die Hauptversion kann aus einer beliebigen Zahl bestehen – bei der Nebenversion sollte man mindestens “zweistellig” vorgehen. Anstelle einer 3.1 sollte man daher besser eine 3.01 verwenden. So ist es später problemlos möglich, nach der 3.09 noch weitere Versionen anzubieten. Vorsichtigere Naturen verwenden für die Nebenversion sogar eine dreistellige Zahl: 3.009. Dies sollte man jedoch nur bei Paketen vornehmen, von denen man weiß, dass sie sich häufig verändern und die Erhöhung der Revisionsnummer nicht verwendet werden kann. Ist man jedoch in die “.9-Falle” getreten, empfiehlt es sich für die neue Version einen weiteren Zahlenblock anzuhängen: 3.9.01. Das sieht zwar nicht so schön aus, rettet einen jedoch aus der misslichen Lage die Version 4.00 einzuführen.

Autor: Martin Niemann