it-swarm-eu.dev

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

Was ich über Build-Nummern denke, ist, dass jedes Mal, wenn ein neuer nächtlicher Build erstellt wird, eine neue BUILDNUMBER generiert und diesem Build zugewiesen wird. Für meine 7.0-Versionsanwendung werden die nächtlichen Builds 7.0.1, 7.0.2 usw. sein. Ist es so? Was nützt dann eine REVISION nach der Build-Nummer? Oder wird der REVISION-Teil nach jedem nächtlichen Build erhöht? Ich bin hier ein wenig verwirrt ... bezeichnen wir jeden nächtlichen Build als [~ # ~] Build [~ # ~] ?

Das Format wird hier erwähnt: AssemblyVersion - MSDN

56
A9S6

Ich habe es noch nie in dieser Form geschrieben gesehen. 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 dem zugrunde liegenden Betriebssystem), MINOR eine Nebenversion (möglicherweise einige neue Funktionen) In einer früheren Hauptversion ist REVISION normalerweise ein Fix für eine frühere Nebenversion (keine neuen Funktionen), und BUILDNUMBER wird für jede neueste Version einer Revision erhöht.

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

58
tcrosley

Die ganze Verwirrung rührt von der unterschiedlichen Semantik her, 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, wenn 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 werden als austauschbar angesehen, und das 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:

  • commit-Nummer 4711: Alice hat Feature A hinzugefügt
  • CI erzeugt Build 1.2.3.100
  • commit-Nummer 4712: Bob hat die Funktion B geändert
  • commit-Nummer 4713: Alice hat Feature A behoben (der "Hotfix")
  • CI erzeugt Build 1.2.3.101

major.minor.revision.build

Wie Sie sehen können, ist der Hotfix nicht die einzige Änderung, die im nächsten Build enthalten ist. 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 einen Build-Zweig 1.2.100
  • CI erzeugt Build 1.2.100.0
  • commit-Nummer 4712: Bob hat Feature B in Trunk/Master geändert
  • commit-Nummer 4713: Alice hat Feature A im Zweig 1.2.100 behoben
  • CI erzeugt Build 1.2.100.1

major.minor.build.revision

Der Begriff REVISION kann sich beziehen

  • a product revision (that's how most people use it)
  • eine Überarbeitung 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 und an welchem ​​Punkt des Prozesses die Verzweigung erfolgt. Dieser Aspekt wird wichtig, wenn Sie jederzeit nach erfolgreichem Test 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 genauso implementiert werden - ein Tag ist nichts anderes als ein Zweig unter /tags.

Siehe auch

Aus dem Abschnitt FAQ at TFS-Verzweigungsstrategie :

In welcher Filiale soll ich das P1 (Hotfix) Ticket reparieren?

  • Der P1 sollte in dem Zweig festgelegt 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 den Fix 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.

  • Jetzt können Sie argumentieren, ob es sicher ist, direkt gegen den Prod-Zweig zu arbeiten. Denken Sie noch einmal darüber nach, 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

20
JensG

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

major.minor [.build [.revision]]

Die Komponenten werden konventionell wie folgt verwendet:

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 Assemblys identisch sind, die Nebenversionsnummer jedoch unterschiedlich ist, weist dies auf eine signifikante Verbesserung mit der Absicht der Abwärtskompatibilität hin. Diese höhere Nebenversionsnummer 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

17
Cole Campbell

Es gibt mindestens ein paar verschiedene Dinge, die ich mir als Referenz für die Build-Nummer vorstellen könnte:

  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. Continuous Integration Server Identifier. 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 mag andere geben, die ich nicht kenne, aber dies sind die großen, die ich kenne, wenn es um Zahlen auf Codebasis geht.

4
JB King

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.

3
user1249

Die Revision kann für Patches der Builds verwendet werden. 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, ihn zu verwenden. Team 1 rückt auf 1.0.51.0 vor, wenn Team 2 ein Problem in 1.0.43.0 findet.

Jetzt nimmt Team 1 diesen Build (43), behebt das Problem und stellt Team 2 den Build 1.0.43.1 zur Verfügung. Das Update wird möglicherweise auch im Haupt-Build weitergegeben, sodass die Änderung in 1.0.52.0 angezeigt wird.

Hoffe das ist klar und hilfreich.

* Revision ist nützlich, wenn nicht alle am Projekt Beteiligten denselben Build verwenden und Sie bestimmte Builds patchen müssen.

2

Lassen Sie mich nur sagen, wie ich es sehe und benutze ...

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 des gleichen Geschlechts schreiben werde (Beispiel: Zugang v1 - Zugang v-2 - Zugang v-3 * alle das gleiche Programm, aber komplett neu geschrieben).

moll: Dies bedeutet, dass ich dem aktuell veröffentlichten Projekt Funktionen hinzufüge. 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 verwende ich, um sehr kleine Änderungen in der veröffentlichten major.minor-Version anzuzeigen. Dies kann eine Änderung des Layouts, des Farbschemas usw. sein.

revision: Dies wird verwendet, um eine Fehlerbehebung in der aktuell veröffentlichten Datei major.minor.build anzuzeigen. - Es gibt Fälle, in denen ich das aktuelle Projekt nicht weiterentwickle und ein Fehler auftritt. 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 fertiges oder blockiertes Projekt weiterhin repariert und nutzbar gemacht werden, bis die nächste Version veröffentlicht wird.

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.

2
Richard Rindom

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 kommen würden. Ich nehme an, wenn Sie einige der nicht erstellten Ressourcen (Symbole, DB-Skript usw.) geändert haben, haben die meisten Projekte, an denen ich in letzter Zeit gearbeitet habe, all diese Dinge auch unter Versionskontrolle, sodass der Erstellungsprozess sie abholt, wenn Installer/Release machen. Ich mag zeitgestempelte Build-Nummern, obwohl nicht ganz so, wie @David es beschreibt (ich mag major.minor.revision.HHMM). Bei meiner Arbeit verwenden wir jedoch nur eine fortlaufende Nummer, die unser Build-Server generiert.

1
TMN

Wie bei jkohlhepp verwenden wir den dritten Teil der Version, um die Versionsnummer in Subversion anzuzeigen, und den vierten, um die Build-Nummer von unserem Continuous Integration Server (Jenkins für uns) anzuzeigen. Dies bietet uns mehrere Vorteile: Wenn die von unserem CI-Server festgelegte Versionsnummer einen manuellen Schritt entfernt, der sonst versehentlich übersehen werden könnte. Es ist leicht 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 mit dem Code zu verknüpfen, aus dem sie generiert wurde nd dem CI-Job, der sie erstellt hat, indem wir uns nur die Versionsnummer ansehen - was wir gelegentlich sehr nützlich finden.

1
Jon Lawson

Es ist was immer du willst. 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 tun Sie wollen es sein. Sie müssen es so gestalten, dass Sie zu der Quelle gelangen, aus der diese Ausgabe erstellt wurde. Was auch immer Sie dazu befähigen.

0
BlackICE

Die letzten beiden Ziffern sind die Gesamtzahl der Builds

1.01.2.1234

die Build-Nummer ist 2.1234, aber die meisten Leute verwenden nur 1234, da sich der 2-Teil nicht häufig ändert.

0
lance lyons

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 Erstellungsprozesses eine neue AssemblyInfo-Datei mit den richtigen #s.

0
RationalGeek