Für den Aufbau der Versions-Nummern in OPDE verwende ich folgendes Schema:
MAJOR.MINOR.RELEASE.BUILD
oder als Beispiel:
1.13.1.341
Das liest sich dann wie folgt:
MAJOR: Eine Erhöhung der Version 1.x auf 2.x träte dann nur dann ein, wenn das Programm vollständig neu aufgebaut würde.
MINOR: Eine „kleinere“ Versionsanhebung geschieht immer dann, wenn ich neue Funktionen in das bestehende Programm einbaue.
RELEASE: Die „Veröffentlichungen“ werden immer dann angehoben, wenn ich Fehler bereinigt habe, aber ansonsten keine neuen Funktionen erstellt wurden.
BUILD: Neben diesen drei Versions-Elementen gibt es noch den BUILD. Der ist aber nur für diejenigen interessant, die an der Software-Entwicklung beteiligt sind. Der Vollständigkeit halber, möchte ich das aber hier dennoch erwähnen. Der „Build“ ist eine rein technische Angabe. Das müssen Sie sich so vorstellen, dass jedes mal, wenn ich eine Änderung am Programm vornehme und diese dann in Maschinensprache übersetzen lasse, diese Nummer um 1 erhöht wird. Somit bedeutet z.B. die Build-Nummer 211, dass wir bisher (in diesem Release) 211 mal etwas geändert und neu übersetzt haben. Jedes mal, wenn wenn sich der BUILD erhöht, wird auch der BUILDDATE gesetzt. Das ist einfach der jeweilige Zeitpunkt verkehrt herum aufgeschrieben. So steht z.B. das BUILDDATE: 20150827162050 für den 27.08.2015 16:20:50 Uhr.
Sobald eine höhere Versions-Komponente angehoben wird, werden alle nachfolgenden auf 1 gesetzt. Sollte also irgendwann mal eine Version 2.x rauskommen, wäre ihre erste Version dann 2.1.1.1
| 2023/05/23 12:56 | Torsten Löhr |
| 2022/02/17 13:26 | Torsten Löhr |
| 2021/07/26 14:19 | Torsten Löhr |
| 2019/08/07 08:40 | Torsten Löhr |
| 2019/03/13 09:56 | Torsten Löhr |
| 2019/01/17 10:54 | Torsten Löhr |
| 2019/01/11 12:46 | Torsten Löhr |
| 2019/01/11 12:44 | Torsten Löhr |
| 2019/01/11 12:41 | Torsten Löhr |
| 2016/07/28 14:09 | Torsten Löhr |