Versionsnummern bei mehreren Versionszweigen

[Union]

Ich verwende keine (automatische) Build-Nummer. Ich zähle die manuell hoch, bei jeder Veröffentlichung (auch Testversionen). Dabei verwende ich nur 1 Stelle, so dass ein Überlauf in die nächsthöhere Stelle erfolgt und ein enstprechendes Setzen auf Null. Die Folge ist, dass es Lücken im Produktiveinsatz bei den Buildnummern gibt (also an der letzten Stelle).

Ich verwende auch eine "dynastische" Versionsvergabe, wenn es mal einen umfangreichen Sprung gab. Dies aber bloß als Zusatz, damit sich die User das leichter merken können. Dafür Suche ich mir für jedes Programm oder Paket etwas entsprechendes aus (Pharaonen, griechische Götter etc.). Das wird ja seit Jahrzehnten z.b. bei Intel (aber meist mit Städte- oder Regionsnamen) gemacht. Android verwendet Süßigkeiten ;)

Ergebnis ist dann sowas wie "1.9.2.7 (Hephaistos)"

[generic]

Was Versionsnummern betrift gibt es einen quasi Standard.
Semantic Versioning

Meine Arbeitsweise:
a.b.c

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Ich führe in jedem Teil eine Versionsnummer mit, da ich alles als getrenntes Projekt betrachte - also
1) Programm-Version
2) Datei-Version
3) Datenbank-Version

Aus Sicht des Programms/Clients gibt es dann ein Kompatibilitätsbereiche - Client weiß womit er kann. Datenbank zu alt - Client zu alt etc.
Ich führe Datenbankskripte welche jeweils zu nächsten Version migrieren können. Diese werden allerdings nicht automatisch ausgeführt.

Meine Dateien basieren meist auf XML mit Schema. Falls es ein neues Dateiformat gibt, konvertiere ich diese via XSD - allerdings nur für den Upgrade-Pfad auf die nächste höhere Version. Unter Umständen werden dann mehrere Upgrades ausgeführt, wenn eine Datei geöffnet wird.

Durch die XSDs und die Versionsnnummern kann ein Client dann sehr gut eingrenzen mit welchen Dateiversionen er kann und welche nicht.

[RWarnecke]

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

[generic]

Zitat:

Zitat von RWarnecke (Beitrag 1236773)

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

Ich zähle jede Roadmap welche Bugs oder Features zusammenfasst bzw. ein MSI welches hinten herausfällt.

[Sherlock]

Zitat:

Zitat von generic (Beitrag 1236905)

Zitat:

Zitat von RWarnecke (Beitrag 1236773)

Zitat:

Zitat von generic (Beitrag 1236770)

a) Hauptversion wird nur erhöht wenn "from scratch" angefangen wird / bei Erhöhung b und c wird auf 0 gesetzt.
b) bei jedem neuen Feature-Release +1 / bei Erhöhung wird c auf 0 gesetzt.
c) bei jedem Bugfix-Release +1

Eine Frage, Du zählst aber nicht für jeden Bug oder jedes neue Features +1 bei b) und c) oder ?

Ich zähle jede Roadmap welche Bugs oder Features zusammenfasst bzw. ein MSI welches hinten herausfällt.

Jupp, genau so machen wir es auch. Der Buildcount an vierter Stelle wird nur benötigt, um unterschiedliche Testdurchläufe unterscheiden zu können, und wird mit jeder Änderung an den ersten drei Stellen auf 0 zurück gesetzt.

Sherlock

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1236907)

Jupp, genau so machen wir es auch. Der Buildcount an vierter Stelle wird nur benötigt, um unterschiedliche Testdurchläufe unterscheiden zu können, und wird mit jeder Änderung an den ersten drei Stellen auf 0 zurück gesetzt.

Ich hatte das mal versucht von Anfang an unterbrechungsfrei fortlaufend hochzuzählen, um zur Versionsnummer eine quantitative Zählung mitzunehmen.
So wie die Revision bei den Delphi/RAD-Versionen.

D7 7.0.8.1 / 7.0 (Build 4453) => Major.Minor Build (Dateiversion / Programmversion)
XE 15.0.3953.35171 => Major.Minor.Revision.Build
XE2 16.0.4429.46931
XE3 17.0.4625.53395
XE3 17.0.4770.56661 (Update 2)
XE4 18.0.4905.60485
XE5 19.0.13856.4978 => Major.Minor.xxx.Revision ???

k.A. wo z.B. die Delphi-Updates ersichtlich sind, außer in "Installierte Aktualisierungen" und in Revision/Build



Dank einer fortlaufenden Revision/Build hätte man für die Versionsnummern von einzelnen Modulen/Versionszweigen noch die Info, wievielte Version das wirklich ist
und kann so das Major+Minor in gemeinsammen Schritten über das gesamte Projekt zählen, jenachdem wann das jeweilige Modul zuletzt aktualisiert wurde.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1236912)

Ich hatte das mal versucht von Anfang an unterbrechungsfrei fortlaufend hochzuzählen, um zur Versionsnummer eine quantitative Zählung mitzunehmen.

Ja, das war eigentlich auch mein Ziel. Es ist intern einfach effizienter mit nur einer einzigen Zahl zu kommunizieren. Aber es ist halt etwas schwierig, dem Build-System diese zentrale Zahlenvergabe beizubringen, wenn man unterschiedliche Revisions-Branches hat und zusätzlich noch mit Distributed Builds arbeiten möchte. Ich habe da gerade Continua am Wickel, bin aber noch nicht so richtig überzeugt.

Zitat:

Zitat von himitsu (Beitrag 1236912)

XE3 17.0.4625.53395
XE5 19.0.13856.4978 => Major.Minor.xxx.Revision ???

Ergänzend:

XE3 17.0.4770.56661 (Update 2)
XE4 18.0.4905.60485

Da ist dann irgendwann wohl das Word für die Build-Nummer übergelaufen, was zu einem wie auch immer gearteten Sprung (ca. 8000 oder $2000) in der Revision geführt hat.

[Sherlock]

IMHO erlaubt die Buildnummer keine zuverlässigen Aussagen, vor allem wenn im Team entwickelt wird. Sie ist einzig eine tolle Zahl, die irgendwie immer größer werden könnte.
Es gibt nur die Methode zu einem Release alle vier Stellen zu dokumentieren (in Release Notes oä), um wirklich zu wissen, was wann tatsächlich raus gegangen ist.
Effizienz in der Kommunikation kann ich bei Buildnummern jenseits der 20 ohnehin nicht erkennen, da sind Zahlendreher und sonstige Missverständnisse deutlich öfter zu erwarten als wenn man schlicht von einer Version "Drei Sieben Fünf Zwo" spricht.
Verdeutlichung: "Drei Sieben Fünf Zwo" vs "Drei Sieben Fünf eintausenvierhundertfünfundzwanzig" oder meinetwegen auch "Drei Sieben Fünf Eins Vier Fünf Zwo Null"
Die vierte Stelle kann zu nichts dienen, ausser zum (pardon my french) Schwanzvergleich ;)

Sherlock

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1236928)

Die vierte Stelle kann zu nichts dienen, ausser zum (pardon my french) Schwanzvergleich ;)

Nja, bisher führe ich die 4. Stelle noch mit (wenn ich sie nicht vergesse hochzusetzen), aber im Programm (z.B. Info-Dialog) wird sie eh nicht mit angezeigt.
> sie Manifest-Creator > da gibt es nur Major+Minor und ein Patch größer 0 wird als Buchstabe angehängt.