Woher kommt die Versionsnummer?

Question

Ich habe ein Versionskontrollsystem (z. B. Subversion) und jetzt möchte ich einen Build-Prozess einrichten. Jetzt muss ich eine Versionsnummer erstellen und in das System einfügen. Aber woher kommt die Versionsnummer? Angenommen, ich möchte dieses gemeinsame < Haupt> verwenden. < minor>. < Bugfix/Revision> Schema. Soll ich eine Nummer an das Build-Skript übergeben? Oder sollte ich Argumente wie erhöhenMajor, erhöhenMinor, erhöhenRevision übergeben? Oder empfehlen Sie, eine Verzweigung mit der Nummer zu erstellen, die vom Build-Skript erkannt wird?

Ich könnte mir vorstellen, dass die Haupt- und Nebenversionsnummer irgendwo manuell eingegeben werden muss. Die Revisionsnummer könnte automatisch erhöht werden. Aber ich weiß immer noch nicht, wo ich die Haupt- und Nebennummer setzen würde.

In meinem Fall habe ich einige PHP-Dateien, die ich gerne zippen würde, aber bevor ich einige Versionsnummern in PHP-Datei einfügen muss.

---

ich bearbeitet habe diesen Beitrag zu versuchen, meine Anfrage klarer zu machen:

Ich benutze keine Subversion, das war nur ein Beispiel. Und ich möchte das Versionsnummernschema nicht diskutieren.

Stellen Sie sich vor, ich möchte Version 3.5.0 oder 3.5.1 erstellen. Würde ich diese Versionsnummer an ein Build-Skript übergeben? Würde das Skript den Zweig im Repository mit dieser Nummer erstellen, oder würde es erwarten, dass jemand diesen Zweig bereits erstellt hat? Manuell? Oder würde das Build-Skript nach dem Namen der Verzweigung (z. B. "3.5.1") suchen und es für weitere Dinge verwenden? Und kommt die Versionsnummer aus meinem Gehirn oder wird sie automatisch erstellt (ich denke, die Major/Minor-Nummer kommt von meinem kleinen Gehirn und der Revisionsnummer)? Oder würden Sie die Nummer in eine Datei einfügen, die möglicherweise in das Repository eingefügt wird?

Ich denke, wenn ich ein Release-Management-Tool verwenden würde, würde ich die Versionsnummer dort einfügen. Aber ich benutze noch keinen.

Answer 1

Für Subversion, nehmen Sie entweder die globale Revisionsnummer und verwenden Sie diese als "Build" -Nummer oder, noch besser, verlassen Sie sich nicht darauf und verwalten Sie Versionen mit Tags und/oder Verzweigungen. Das Hauptproblem bei der globalen Revision ist genau das, es ist global für das Repo. Es wird zunehmen, obwohl sich einige Teile des Repos nicht ändern.

Vollständig Disassociate-Versionen von den Repo-Revisionen ist IMHO besser. Du hast Tags, benutze sie.

Answer 2

Die Revision in svn oder einem anderen Versionskontrollsystem ist nicht dasselbe wie Ihre Produktversionsnummer (oder sogar Ihre Buildnummer).

Es gibt viele Möglichkeiten, wie Sie die Versionsnummer erzwingen können. Normalerweise können Sie in subversion eine Verzweigung (oder ein Tag, sie sind im Wesentlichen die gleiche Sache) für einen Build erstellen und wenn dies eine Release-Version ist, erstellen Sie ein Tag für dieses z. B. svn: //my-repo/releases/1.0.0

Sie könnten entweder einen Parameter in Ihr Build-Skript übergeben, um den Code zu erhalten und diesen als Build-Nummer verwenden, oder ein Verzeichnis, das Ihr Build-Skript verwendet, und svn wechseln Sie zu dem Zweig, den Sie erstellen wollten, dem Skript könnte svn info verwenden, um festzustellen, welche Version es erstellt hat.

Answer 3

x.y.i.j 

Wo x - Hauptversion, y - Minor-Version, i - Build-Nummer, j - Revisionsnummer

Major version Schritte auf große Veränderungen (neue Architektur, neue UI, etc.)

Minor version Erhöht sich bei kleinen Änderungen (Leistungsverbesserung, große Fehlerbehebung, usw.),

Build number Inkremente Evert du veröffentlichst eine öffentliche Veröffentlichung.

Revision number wird jedes Mal inkrementiert, wenn Sie Änderungen an der Projektquellstruktur festschreiben.

Ich ziehe 0 als Revisionsnummer in AssemblyInfo.cs zeigen und die reelle Zahl im Namen des Release-Pakets (foo-1.1.7.110-source.zip) mit allen bisherigen über die Verwendung von

Answer 4

vereinbarten Punkt Zweige und Tags. Zusätzlich können die Zweignamen und Tag-Namen in einen Build-Prozess mit einigen cleveren Skripten integriert werden.

Der einzige Leckerbissen, den ich hinzufügen möchte, ist, dass Sie Ihre SVN-Revision in jeden Build schleichen sollten. Manchmal ist es einfach, zu einem bestimmten Punkt mit der Revision zurückzukehren, anstatt das Tag oder den Zweig zu kennen. 99% der Tag/Zweig ist gut genug, aber die Revision eignet sich hervorragend für inkrementelle/interne/kontinuierliche/Test-Builds.

Answer 5

Alle Zweige sollten manuell erstellt werden. Das Build-Skript sollte mit einem Tag und/oder einer Verzweigung arbeiten, beginnend mit dem Auschecken (oder es kann aktualisiert werden). Als Teil des Build-Prozesses ist es eine gute Idee, ein Tag für den genauen Snapshot zu erstellen, der erstellt wird.

Sie hätten normalerweise Build-Nummer und eine Version. Die Build-Nummer kann automatisch erhöht und als Teil des Builds in die Versionskontrolle eingecheckt werden (außer beim Tag-basierten Build, bei dem die Build-Nummer außerhalb des Repository bleiben muss - ein weiterer Grund, um tagbasierte Builds zu vermeiden).

Die Version wird normalerweise in einer Datei gespeichert, die Sie einmal pro Veröffentlichungszyklus manuell aktualisieren. Es wird in einen hellen Zweig eingecheckt und dann in Ruhe gelassen. Zum Beispiel hätte die Mainline Version = "3" in ihrer Datei, die erste Version in Release Branch hätte Version = "3.5", und wenn eine Patch-Version benötigt wird, verzweigen Sie diese von Ihrem Release-Zweig und checken Version = ein "3.5.1"