Was genau ist die Build-Nummer in MAJOR.MINOR.BUILDNUMBER.REVISION

Ich habe noch nie gesehen, dass es in dieser Form geschrieben wurde. Wo ich arbeite, verwenden wir das Formular MAJOR.MINOR.REVISION.BUILDNUMBER, wobei:

• MAJOR eine Hauptversion ist (normalerweise viele neue Funktionen oder Änderungen an der Benutzeroberfläche oder zugrunde liegendes Betriebssystem)
• MINOR ist eine Nebenversion (möglicherweise einige neue Funktionen) einer früheren Hauptversion
• REVISION ist normalerweise ein Fix für eine frühere Nebenversion (keine neuen Funktionen)
• BUILDNUMBER wird für jeden letzten Build einer Revision erhöht.

Beispielsweise kann eine Revision für die Qualitätssicherung freigegeben werden, und es tritt ein Problem auf, das auftritt erfordert eine Änderung. Der Fehler wurde behoben und mit derselben REVISION-Nummer, aber einer inkrementierten BUILDNUMBER an die Qualitätssicherung zurückgegeben.

Kommentare

• +1: That ‚ ist so ziemlich so, wie ich es ‚ überall gesehen habe. Ich ‚ habe gesehen und gemocht, wie einige Unternehmen nur einen DateTime-Stempel für die BUILDNUMBER verwenden.
• +1: Die “ MAJOR.MINOR.REVISION.BUILDNUMBER “ Form ist verständlich und sinnvoll. Ich habe das BUILDNUMBER.REVISION-Formular auf der MSDN-Site gesehen (Link in Frage aktualisiert) und es hat mich total verwirrt.
• Odd. Ich würde erwarten, dass die letzte Revision am sinnvollsten ist – ‚ ist die Nummer, die sich (wahrscheinlich) am meisten ändert.
• @Izkata, eigentlich der Build Die Anzahl ändert sich am meisten, zumindest die Art und Weise, wie wir sie derzeit in meinem Hauptvertrag verwenden, der eine strikte Versionskontrolle verwendet, weil wir medizinische Geräte herstellen. Eine aktualisierte Version zeigt an, dass die vorherige Software behoben wurde, die von der Qualitätssicherung (QS) getestet werden muss. Dies ist eine völlig separate Abteilung, die drei Tage lang umfangreiche Tests durchführt (gemäß FDA-Richtlinien). Wenn sie Probleme feststellen, sind möglicherweise zusätzliche Codeänderungen erforderlich, die einen neuen Build (Neukompilieren und Verknüpfen) und einen erneuten Test erfordern. Die Versionsnummer bleibt jedoch gleich.
• @tcrosley Ich denke, es ist ‚ ist ein Fall unklarer Terminologie. Ich habe über Revisionen in der Versionskontrolle nachgedacht.

Die ganze Verwirrung rührt von der verschiedene Semantik , die MS für „Build number“ und insbesondere „Revision“ verwendet. Die Begriffe bedeuten nur verschiedene Dinge.

Die meisten Leute (ich eingeschlossen) verwenden ein semantisches Versionsnummerierungsschema , bei dem Sie nur eine höhere BUILD-Nummer erhalten wann immer Sie aus irgendeinem Grund einen neuen Build erstellen müssen. Für uns ist ein Hotfix nur eine weitere Codeänderung, und der BUILD-Teil wird bei jedem CI-Lauf automatisch erhöht. Module mit demselben MAJ.MIN.REV gelten als austauschbar, und BUILD teilt Ihnen mit, welches das neueste ist.

Das Inkrementieren von REVISION weist jedoch auf einen neuen Zweig für permanente Releases hin. Deshalb platzieren wir ihn vor BUILD.Der Nachteil dieses Ansatzes ist, dass wir möglicherweise die folgende Abfolge von Ereignissen erhalten:

• Festschreibungsnummer 4711: Alice hat Feature hinzugefügt. A
• CI erzeugt Build 1.2.3.100
• Commit-Nummer 4712: Bob hat Feature B geändert
• Commit-Nummer 4713: Alice hat Feature A (den „Hotfix“) behoben
• CI erzeugt Build 1.2.3.101

Wie Sie sehen, ist der Hotfix nicht die einzige Änderung, die in der nächsten enthalten ist Build, auch Bobs Modifikation wird Teil dieses Builds. Wenn Sie den aktuellen Zweig stabilisieren möchten, können Probleme auftreten, da Sie nie sicher sein können, ob Bob gerade eine Reihe von Fehlern hinzugefügt hat oder nicht.

MS verwendet beide Begriffe unterschiedlich. Die BUILD-Nummer wird nicht automatisch erhöht, sondern kann als eine Art Release-Zweig betrachtet werden, um den für eine bestimmte Version des Codes verwendeten Code einzufrieren. Die REVISION zeigt zusätzliche „heiße“ Änderungen an, die auf diesen BUILD-Zweig angewendet werden. Die Reihenfolge wäre daher wie folgt:

• Commit-Nummer 4711: Alice hat Feature A zu Trunk / Master hinzugefügt.
• Carl erstellt den Build-Zweig 1.2.100
• CI erzeugt Build 1.2.100.0
• Festschreibungsnummer 4712: Bob hat Feature B in Trunk / Master geändert Im Zweig 1.2.100
• erzeugt CI Build 1.2.100.1

Der Begriff REVISION kann sich auf

• ein Produkt Revision (so verwenden es die meisten Leute)
• eine Revision eines bestimmten täglichen Builds (das macht MS)

Der Hauptunterschied zwischen den beiden Prozessen besteht darin, ob Sie Hotfixes auf CI-Builds anwenden möchten oder nicht. An diesem Punkt des Prozesses wird die Verzweigung vorgenommen. Dieser Aspekt wird wichtig, wenn Sie nach erfolgreichem Test jederzeit einen bestimmten Build auswählen und genau diese Version für die nächste offizielle Version Ihres Produkts bewerben möchten.

In unserem Fall erstellt das CI-Tool ein Repository-Tag, sodass wir bei Bedarf immer die erforderlichen Informationen zur Verfügung haben. Mit SVN wird es noch einfacher, da Tags und Zweige genau auf die gleiche Weise implementiert werden – ein Tag ist nichts anderes als ein Zweig, der sich unter /tags befindet.

Siehe auch

Aus dem FAQ-Bereich unter TFS-Verzweigungsstrategie :

In welchem Zweig sollte ich das P1-Ticket (Hotfix) reparieren?

• Das P1 sollte in dem Zweig repariert werden, der der in der Produktion ausgeführten Codebasis am nächsten liegt. In diesem Fall sollte der P1 im Prod-Zweig fixiert werden. Wenn Sie das Update in einem anderen Zweig anwenden und die Änderungen in der Produktion einführen, besteht die Gefahr, dass halbfertiger oder nicht getesteter Code aus den nachfolgenden Iterationen freigegeben wird.

• Nun können Sie argumentieren, ob dies der Fall ist Denken Sie noch einmal daran, dass ein P1, der sofortige Aufmerksamkeit erfordert, kein grundlegendes Problem im System sein sollte. Falls es sich um ein grundlegendes Problem handelt, sollte es dem Product Backlog hinzugefügt werden, da dies möglicherweise eine weitere Analyse und Diskussion mit dem Kunden erfordert.

Eine weitere gute Lektüre ist die TFS-Verzweigungsanleitung

Kommentare

• Das ist eine gute Antwort! +1

Microsoft beschreibt den Zweck jeder Komponente einer .NET-Versionsnummer in ihrer MSDN-Dokumentation für die Klasse Version. Hier ist der relevante Teil:

major.minor [.build [.revision]]

Die Komponenten werden gemäß Konvention als verwendet folgt:

Major: Baugruppen mit demselben Namen, aber verschiedenen Hauptversionen sind nicht austauschbar. Eine höhere Versionsnummer weist möglicherweise auf eine größere Neufassung eines Produkts hin, bei der keine Abwärtskompatibilität angenommen werden kann.

Minor: Wenn der Name und die Hauptversionsnummer auf zwei Baugruppen identisch sind, die Nebenversionsnummer jedoch unterschiedlich ist, Dies weist auf eine signifikante Verbesserung mit der Absicht der Abwärtskompatibilität hin. Diese höhere kleinere Versionsnummer weist möglicherweise auf eine Punktversion eines Produkts oder eine vollständig abwärtskompatible neue Version eines Produkts hin.

Build: Ein Unterschied in der Build-Nummer stellt eine Neukompilierung derselben Quelle dar. Bei Änderungen des Prozessors, der Plattform oder des Compilers können unterschiedliche Build-Nummern verwendet werden.

Revision: Baugruppen mit demselben Namen, denselben Haupt- und Nebenversionsnummern, aber unterschiedlichen Revisionen sollen vollständig austauschbar sein. Eine höhere Versionsnummer kann in einem Build verwendet werden, der eine Sicherheitslücke in einer zuvor freigegebenen Assembly behebt.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Kommentare

• Es verwirrt mich, warum niemand diesen Standard kennt. Jede Antwort hier behauptet, dass Build am Ende steht und nicht ‚
• +1 für geändert wurde Eine Antwort mit einer berechtigten Build-Nummer. Das bloße Erhöhen der Anzahl ist ziemlich nutzlos, wenn die Revision gleich bleibt (es sei denn, Sie haben ein verrücktes Build-System, das zeitabhängig ist). Verwenden der Build-Nummer, um zu signalisieren, welcher Compiler, welche Plattformen usw. nützlich ist.
• Build als recompilation of the same source scheint ein wichtiger Punkt zu sein, der übersehen wird. Wenn ‚ eine Codeänderung ist (für die ‚ keine ganz neue Major / Minor-Erhöhung erforderlich ist), wird die Revision muss ebenfalls geändert werden.
• @PeterX Wie bei Build-spezifischen Änderungen beim erneuten Targeting?
• “ Ein Unterschied in der Build-Nummer stellt eine Neukompilierung derselben Quelle dar. “ scheint der Dokumentation zu widersprechen. Sobald Sie eine Revision vorgenommen haben, ist dies nicht mehr dieselbe Quelle. BUILD vor REVISION zu haben, ist nur dann sinnvoll, wenn eine Revision spezifisch für einen Build ist, der einen “ Prozessor-, Plattform- oder Compilerwechsel “ darstellt. Ich denke also, was die meisten als REVISION-Beule sehen, sollte bei Verwendung dieser Beschreibungen wirklich eine kleine Beule sein. In den Dokumenten wird zwar die Verwendung von REVISION für Hotfixes erwähnt, es wird jedoch davon ausgegangen, dass Hotfixes für alle Builds gelten und daher eine geringfügige Beeinträchtigung darstellen sollten. Ich möchte nur eine logische Konsistenz !!

Es gibt mindestens ein paar verschiedene Dinge, die ich könnte Stellen Sie sich die Build-Nummer vor, auf die verwiesen wird:

1. Versionsverwaltungsversion, die veröffentlicht wurde. Wenn es beispielsweise eine Version von Revision Nr. 12345 gab, kann dies nachverfolgt werden, indem die Build-Nummer angegeben wird. Wenn sie gepatcht ist, werden möglicherweise Revisionen angezeigt, da es sich nicht um neue Funktionen handelt, die die Haupt- oder Nebenversionen erhöhen würden und die Build-Nummer muss gespeichert werden, falls jemand diesen Build erneut ausführen möchte.

2. Kennung des Continuous Integration Servers. In diesem Fall kann der CI-Server jeden Build nummerieren, den er ausführt und daher ist die Build-Nummer das, was ein erfolgreicher Build erhält, und der Revisionsteil wird in diesem Szenario nicht benötigt.

Es kann andere geben, die ich nicht kenne, aber Dies sind die großen, die ich kenne, wenn es um Zahlen auf Codebasis geht.

Kommentare

• +1 für # 1. Ich verwende gerne die Revision # der Quellcodeverwaltung, da dies das Nachschlagen von Fehlern, die für diese Version in der Quellcodeverwaltung gemeldet wurden, erheblich vereinfacht.
• @MasonWheeler: Funktioniert hervorragend, wenn Sie sich in SVN befinden. Wenn Sie jedoch zu dcvs gelangen, landen Sie diese bekommt Eichhörnchen y. Dies wäre eine Sache, die ich am meisten vermisse, wenn ich ‚ hinzufüge.

Eine Build-Nummer wird normalerweise bei jedem Build erhöht, damit sie eindeutig ist.

Der Einfachheit halber setzen einige die Build-Nummer zurück, wenn die MAJOR- oder MINOR-Nummern gestoßen werden.

Die meisten Continuous Integration-Engines ermöglichen automatisch generierte eindeutige Build-Nummern.

Die Revision kann für Patches der verwendet werden baut. Nehmen wir an, 2 Teams arbeiten an einem Produkt.

Team 1 ist das Hauptentwicklungsteam und erstellt jeden Abend einen Build mit dem folgenden Versionsschema 1.0.X.0, wobei X inkrementiert wird. Jetzt sind sie bei Build 1.0.50.0. Team 2 nimmt von Zeit zu Zeit einen Build vor. Nehmen wir an, sie nehmen den Build der letzten Woche, der 1.0.43.0 ist, und beginnen mit der Verwendung. Team 1 rückt auf 1.0.51.0 vor, wenn Team 2 ein Problem in 1.0.43.0 findet.

Jetzt wird Team 1 dies tun Nehmen Sie diesen Build (43), beheben Sie das Problem und stellen Sie Team 2 den Build 1.0.43.1 zur Verfügung. Der Fix wird möglicherweise auch im Hauptbuild weitergegeben, sodass die Änderung in 1.0.52.0 angezeigt wird.

Hope Dies ist klar und hilfreich.

* Die Überarbeitung ist nützlich, wenn nicht alle am Projekt beteiligten Builds denselben Build verwenden und Sie bestimmte Builds patchen müssen.

Lassen Sie mich nur sagen, wie ich es sehe und verwende …

Programmname version major.minor.build.revision

major: Für mich ist das aktuelle Projekt, an dem ich arbeite. Die Nummer ändert sich erst, wenn ich ein neues Projekt mit demselben Programmnamen starte. Dies bedeutet, dass ich buchstäblich ein neues Programm mit demselben Geschlecht schreibe (Beispiel: access v1 – Zugriff auf v-2 – Zugriff auf v-3 * alle das gleiche Programm, aber komplett neu geschrieben).

Moll: Dies bedeutet, dass ich Anzeige bin Funktionalität für das aktuell veröffentlichte Projekt.Zum Beispiel habe ich die Möglichkeit hinzugefügt, eine Quittung zu drucken oder Bilder zu importieren. Grundsätzlich möchte ich jetzt zusätzliche Funktionen hinzufügen und nicht auf die nächste Hauptversion warten.

build: Dies wird verwendet, um auf sehr kleine Änderungen in der veröffentlichten major.minor-Version hinzuweisen. Dies kann eine Änderung des Layouts, des Farbschemas usw. sein.

Revision: Dies wird verwendet, um auf eine Fehlerbehebung in der aktuell veröffentlichten Datei major.minor.build hinzuweisen. Es gibt Fälle, in denen ich die nicht weiterentwickle aktuelles Projekt und ein Fehler entsteht. Dieser Fehler muss behoben und veröffentlicht werden. Es bedeutet nur, dass ich das, was ich bereits veröffentlicht habe, so repariere, dass es richtig funktioniert. Ich würde dies auch verwenden, wenn ich an einem neuen Build, einer neuen Ergänzung oder einer neuen Hauptversion arbeite. Die veröffentlichte Version muss natürlich gepatcht werden, während wir auf die nächste Haupt-, Neben- oder Build-Version warten.

Auf diese Weise kann ein abgeschlossenes oder blockiertes Projekt noch repariert und bis zur nächsten Version verwendet werden veröffentlicht.

Ich hoffe, dies gibt jemandem ein besseres Verständnis dafür, wie diese Art der Versionierung funktionieren würde (oder sollte). Für mich ist es die einzige Definition und Praxis, die bei dieser Art der Versionierung wirklich Sinn macht.

Ich habe bisher nur eine Build-Nummer als letzte Nummer in der Release-ID gesehen. Ich bin mir nicht sicher, wie Sie zu einer Überarbeitung einer Build-Nummer gekommen sind. Ich nehme an, wenn Sie einige der nicht erstellten Ressourcen geändert haben ( Symbole, DB-Skript usw.), vielleicht, aber die meisten Projekte, an denen ich in letzter Zeit gearbeitet habe, haben all diese Dinge auch unter Versionskontrolle, sodass der Erstellungsprozess sie beim Erstellen des Installationsprogramms / der Version aufgreift. Ich mag zeitgestempelte Build-Nummern, obwohl nicht ganz so, wie @David es beschreibt (ich mag major.minor.revision.HHMM). Wenn ich jedoch arbeite, verwenden wir nur eine fortlaufende Nummer, die unser Build-Server generiert.

Es ist alles, was Sie wollen es zu sein. Ich neige dazu, year.month.day.hhmm für meine major.minor.build.revision zu verwenden. Wenn ich mehr als eine pro Minute produziere, stimmt etwas nicht. Sie können einfach ein einfaches Inkrement verwenden, oder ich habe einige ausgefeilte Generatoren für sie gesehen. Was Sie wollen, ist, dass sie es tun Erstellen Sie diese Ausgabe, was auch immer Sie dazu befähigen.

Unser Team verwendet die dritte Nummer (Revision) als Revisionsnummer aus dem Subversion-Repository. Wir verwenden die vierte Nummer (Build) als Build-Nummer von unserem TeamCity Continuous Integration Server, der den Build tatsächlich erstellt. TeamCity erstellt während des Build-Prozesses eine neue AssemblyInfo-Datei mit den richtigen #s.

Wie bei jkohlhepp verwenden wir den dritten Teil der Version, um die Versionsnummer in SubVersion anzuzeigen, und den vierten, um die anzuzeigen Build-Nummer von unserem Continuous Integration Server (Jenkins für uns). Dies bietet uns mehrere Vorteile: Wenn die von unserem CI-Server festgelegte Versionsnummer einen manuellen Schritt entfernt, der sonst versehentlich erfolgen könnte vermisst; Es ist einfach zu überprüfen, ob ein Entwickler keine freche Veröffentlichung von seinem Entwicklungs-PC vorgenommen hat (was dazu führen würde, dass diese Zahlen Null sind). und es ermöglicht uns, jede Software sowohl mit dem Code zu verknüpfen, der aus generiert wurde, als auch mit dem CI-Job, der sie erstellt hat, indem wir uns nur die Versionsnummer ansehen – was wir gelegentlich sehr nützlich finden.

Die letzten beiden Ziffern sind die Gesamtzahl der Builds

1.01.2.1234

Die Build-Nummer ist 2.1234. Die meisten Benutzer verwenden jedoch nur 1234, da sich der zweite Teil nicht häufig ändert.

Kommentare

• Das OP fragt nach der Build-Nummer und nicht nach der Build-Nummer in der Revisions-ID.