Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Das ist bei den einzelnen Softwareherstellern unterschiedlich. Meist ist es aber eine laufende Nummer die mit jedem Compile-Vorgang des "Build-Systems" hochgezählt wird.
Während der Entwicklung arbeitet man eben z.B. an Version 4.1 .. Aber bis 4.1 fertig ist, gibt es immer wieder arbeiten am Code und "gebaute" Zwischenstände die ausprobiert werden müssen. Damit man die einzelnen 4.1er Zwischenstände unterscheiden kann, gibt's u.A. die "Build-Nummer".
was bedeutet der Zusatz "Build" bei der Versionsnummer?
Etwas weiter ausgeholt sieht das so aus:
Eine Software wird i.d.R. auf einen bestimmten Release hin entwickelt, wobei es natürlich sehr verschiedene Vorgehensweisen und Ausprägungen gibt. Eine vielmals verwendete Vorgehensweise wäre wie folgt:
Auch die in Entwicklung befindliche Software hat schon eine Version. War bspw. der letzte Release die Version 1.0.0, so wird die Entwicklung für die Version 1.1.0 weitergehen. Gibt es Bugfixes, so werden die in der letzten Stelle der drei Ziffern der Versionsnummer gezählt. Der erste Bugfix zur Version 1.0.0 wäre also die Version 1.0.1. Das entspricht der Vorgehensweise der Nummerierung in <Major>.<Minor>.<Bugfix>. Obiges Beispiel ist also die allererste Major-Version 1, eben 1.0.0. Werden nun neue Features hinzugefügt, dann wird i.d.R. die Minor-Version erhöht. Um beim Beispiel zu bleiben wäre das dann 1.1.0.
Jetzt kommt die Build-Nummer ins Spiel. Eine Software wird heutzutage vollautomatisch aus dem Quellcode übersetzt (und hoffentlich auch getestet!). Das ist die sog. Continuous Integration. Tools für solche Tasks sind bspw. Jenkins oder TeamCity. Damit wird sichergestellt, dass dieser Vorgang, der sog. "Build" immer exakt identisch abläuft. Das heisst, wenn ein Entwickler ein Änderung in die Versionskontrolle eincheckt, wird das vom Buildsystem bemerkt und die Software automatisch übersetzt sprich "gebaut". Diese Builds haben eine fortlaufende Nummer, welche i.d.R in den About-Dialogen der Software zu sehen ist.
Wie gesagt, es gibt X Ausprägungen, wie das Vorgehen und die Versionsnummern gehandhabt werden. Im OSS-Umfeld hat sich jedoch obiges Schema bewährt. Ich verwende Jenkins und habe mitunter mehrere hundert Jobs, welche die Paketierung der Software bis hin zum vollautomatischen Deployment übernehmen. Soetwas will man nicht von Hand machen, insbesondere wenn es sich um mehr als einige Dutzend Pakete dreht... ;-)
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar