it-swarm.com.de

Welches Versionsnummerierungsschema soll verwendet werden?

Ich suche ein Versionsnummerierungsschema, das das Ausmaß der Änderung, insbesondere der Kompatibilität, ausdrückt.

Apache APR verwenden zum Beispiel das bekannte Versionsnummerierungsschema

<major>.<minor>.<patch>
example: 4.5.11

Maven schlägt ein ähnliches, aber detaillierteres Schema vor:

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Wo ist das Maven-Versionsschema definiert? Gibt es Konventionen für Qualifier und Buildnummer? Wahrscheinlich ist es eine schlechte Idee, Maven zu verwenden, aber nicht dem Maven-Versionsschema zu folgen ...

Welche anderen Versionsnummerierungsschemata kennen Sie? Welches Schema würden Sie bevorzugen und warum?

26
deamon

Hier ist der aktuelle Maven-Versionsvergleichsalgorithmus und eine Diskussion davon. Solange nur die Versionen wachsen und alle Felder mit Ausnahme der Build-Nummer manuell aktualisiert werden, sind Sie in Ordnung. Qualifier funktionieren so: Wenn einer ein Präfix des anderen ist, ist der längere älter. Ansonsten werden sie alphabetisch verglichen. Verwenden Sie sie für Vorabversionen.

Die Verwendung der semantischen Versionierung zum Ausdruck bringen von Kompatibilität zu unterstützen; major steht für nicht abwärtskompatible Änderungen, minor für abwärtskompatible Funktionen und patch für abwärtskompatible Bugfixes. Dokumentieren Sie es, damit Ihre Bibliotheksbenutzer Abhängigkeiten von Ihrer Bibliothek korrekt ausdrücken können. Ihre Snapshots sind automatisiert und müssen nicht erhöht werden, mit Ausnahme des ersten Snapshots nach einer Veröffentlichung, da Präfixe verglichen werden.

25
Tobu

Ich würde den Semantic Versioning-Standard empfehlen, dem auch das Maven-Versionierungssystem zu folgen scheint. Bitte checken sie aus,

http://semver.org/

Kurz gesagt, es ist <major>.<minor>.<patch><anything_else>, und Sie können dem anderen Teil zusätzliche Regeln hinzufügen, wie es Ihnen passt. z.B. -<qualifier>-<build_number>.

23
sixohsix

Der Vollständigkeit halber erwähne ich den alten Apple-Standard für Versionsnummern . Dies sieht aus wie Hauptversion . Nebenversion . Bug-Version . Bühne . Revision ohne Release . Stage ist ein Code aus der Menge d (Entwicklung), a (Alpha), b (Beta) oder fc ( Endkundenschiff - mehr oder weniger das gleiche wie Release Candidate, denke ich).

Das Stadium und die Nicht-Release-Revision werden nur für Versionen verwendet, die keine ordnungsgemäßen Releases aufweisen.

Die erste Version von etwas könnte also 1.0.0 sein. Möglicherweise haben Sie einen Bugfix als 1.0.1, eine neue Version (mit mehr Funktionen) als 1.1 und ein Rewrite oder Major Upgrade als 2.0 veröffentlicht. Wenn Sie dann auf 2.0.1 hinarbeiten wollten, könnten Sie mit 2.0.1d1, 2.0.1d2 bis 2.0.1d153 oder was auch immer beginnen, dann senden Sie 2.0.1a1 an QA, und nachdem sie 2.0.1a37 genehmigt haben , sende 2.0.1b1 an einige willige Spieler, dann, nachdem 2.0.1b9 eine Woche auf dem Feld überlebt hat, brenne 2.0.1fc1 und beginne Abmeldungen zu bekommen. Wenn 2.0.1fc17 genug bekommen würde, würde es 2.0.1 werden und es würde viel Freude geben.

Dieses Format war so standardisiert, dass es ein gepacktes Binärformat und Hilfsroutinen für Vergleiche in den Bibliotheken gab.

6
Tom Anderson

Nachdem ich viele Artikel/QAs/FAQs/Bücher gelesen habe, denke ich, dass [MAJOR]. [MINOR]. [REV] das nützlichste Versionsschema ist, um die Kompatibilität zwischen Projektversionen zu beschreiben (Versionsschema für Entwickler) , nicht für Marketingzwecke).

MAJORchanges ist nicht abwärtskompatibel und erfordert eine Änderung des Projektnamens, des Pfads zu Dateien, GUIDs usw.

MINORchanges ist abwärtskompatibel. Markieren Sie die Einführung neuer Funktionen.

REVfür Sicherheits-/Fehlerbehebungen. Rückwärts und vorwärts kompatibel.

Dieses Versionsschema ist inspiriert von der Versionssemantik von libtool und von Artikeln:

http://www106.pair.com/rhp/parallel.html

HINWEIS: Ich empfehle außerdem, Build/Datum/Benutzerdefiniert/Qualität als zusätzliche Information anzugeben (Build-Nummer, Build-Datum, Kundenname, Release-Qualität):

Hallo App v2.6.34 für Nationalbank , 2011-05-03 , Beta , Build 23545

Aber diese Information ist nicht Versionsinformation!

4
gavenkoa

Beachten Sie, dass ein Versionsnummernschema (wie x.y.0 vs. x.y) durch externe Faktoren eingeschränkt werden kann.

Beachten Sie, dass Ankündigung für Git 1.9 (Januar 2014) :

Ein Release Candidate Git v1.9-rc2 steht nun zum Testen an den üblichen Orten zur Verfügung.

Ich habe Gerüchte gehört, dass verschiedene Tools von Drittanbietern die zweistelligen Versionsnummern nicht mögen (z. B. "Git 2.0") und mit dem Barfing von links und rechts begonnen , wenn die Benutzer v1 installieren .9-rc1.
Während es verlockend ist, sie für ihre schlampige Annahme auszulachen, bin ich auch praktisch und habe nichts dagegen, das kommende Release v1.9.0 anzurufen, um ihnen zu helfen.

Wenn wir diesen Weg gehen (und ich bin im Moment geneigt, diesen Weg zu gehen), lautet das Versionsschema:

  • Der nächste Release-Kandidat ist v1.9.0-rc3, nicht v1.9-rc3.
  • Die erste Wartungsversion für v1.9.0 ist v1.9.1 (und die Nte ist v1.9.N). und
  • Das Feature Release nach v1.9.0 wird entweder v1.10.0 oder v2.0.0 sein, abhängig davon, wie groß der Feature Jump ist, den wir betrachten.
0
VonC