Wie mache ich Versionsnummern?

162

Meine Firma baut ein Produkt. Es wird von SVN versioniert. Es ist eine Web-App, daher wird es im Grunde nie eine Version geben, die einige Funktionen nicht enthält und daher immer als Beta bezeichnet werden könnte. Aber da es sich um ein Unternehmensprodukt handelt, möchte ich die "instabile Überwachung" dort wirklich nicht. Wie würden Sie die Versionierung durchführen? Ist 1.0 stabil? Sollte das Erstellungsdatum in der Versionsnummer sein? Sag mir, was ihr denkt!

Thomaschaaf
quelle
8
Nach einiger Zeit, wenn Sie ~ 6 oder 7 erreichen, sollten Sie zu 2010 (oder was auch immer schönes Jahr) wechseln;)
Anonym
8
Arg ... Bitte, ich bitte dich, nicht. :-D
DevSolar
3
Wechseln Sie nach einigen Jahren mit den Daten wieder zu Zahlen, aber enthalten Sie Schlagworte wie HD , FullHD , 4K , Glutenfrei , was auch immer gerade cool ist. Menschen außerhalb der Softwareindustrie können sich also darauf beziehen.
Emile Bergeron
Vergessen Sie nicht, NIEMALS neue Funktionen in kommende Versionen aufzunehmen. Es gibt immer einen Markt für DLCs. Oh und machen Sie eine Version exklusiv für Frauen, die eine rote Haut haben, und eine für Frauen, die Linkshänder sind, die eine etwas
orangeere

Antworten:

258

[ Dur ]. [ Moll ]. [ Release ]. [ Build ]

Major : Wirklich eine Marketingentscheidung. Sind Sie bereit, die Version 1.0 aufzurufen? Betrachtet das Unternehmen dies als eine Hauptversion, für die Kunden möglicherweise mehr bezahlen müssen, oder handelt es sich um ein Update der aktuellen Hauptversion, das möglicherweise kostenlos ist? Weniger eine F & E-Entscheidung als eine Produktentscheidung.

Moll : Beginnt bei jeder Erhöhung von Dur mit 0 . +1 für jede Version, die an die Öffentlichkeit geht.

Release : Jedes Mal, wenn Sie einen Entwicklungsmeilenstein erreichen und das Produkt auch intern (z. B. zur Qualitätssicherung) veröffentlichen, erhöhen Sie diesen Wert. Dies ist besonders wichtig für die Kommunikation zwischen Teams in der Organisation. Es ist unnötig zu erwähnen, dass Sie niemals zweimal dieselbe Veröffentlichung veröffentlichen (auch nicht intern). Bei Moll ++ oder Major ++ auf 0 zurücksetzen.

build : Kann eine SVN-Revision sein, ich finde, das funktioniert am besten.

Beispiele
Mein aktuelles Chrom: 83.0.4103.61

Assaf Lavie
quelle
6
Dies entspricht fast meiner Definition der Versionierung meiner Software. Ich setze die Version jedoch auf 0 zurück, sobald ich die "kleinere" Versionsnummer erhöhe.
BlaM
3
Was für Minderjährige, wenn Sie Git verwenden?
Brian Carlton
4
@Brain: Schauen Sie sich angit describe
Daenyth
4
Diese Antwort ist so alt ... Ich kann nicht glauben, dass ich jemals SVN verwendet habe. : OIch ​​frage mich, was die beste Vorgehensweise für Git wäre. Vielleicht die ersten paar Ziffern des Commits-Hash? Es gibt also eine gute Chance, ein einzigartiges Match zu bekommen, wenn Sie "git show [build]" machen?
Assaf Lavie
Was ist mit "Alphas" und "Betas"? Erhöhen Sie die Versionsnummer vor oder nach dem Beenden von Alpha oder Beta?
Posfan12
68

xyzg

Inkremente in g sind instabil. (oder RCs) Inkremente in z sind stabile und mittlere Fehlerbehebungen.
Inkremente in y sind stabil und bedeuten neue Funktionen.
Inkremente in x sind stabil, Hauptversion ohne 100% Abwärtskompatibilität.

Itay Moav-Malimovka
quelle
2
Ist das dein Weg oder eine übliche Verwendung?
Canavar
30
Über den G-Punkt bin ich mir nicht sicher, der Rest ist üblich.
Itay Moav -Malimovka
1
Gutes Versionsschema für Komponenten. Aber für ein kommerzielles Produkt verwirrt alles, was über xy hinausgeht, nur den Kunden und erschwert meiner Meinung nach die Kommunikation. Insbesondere Web-Apps, bei denen der Kunde migrieren muss - "Frühzeitig freigeben, häufig freigeben" - wird dort nicht abgeschnitten ...
DevSolar
1
Aber es wäre immer noch gut für das Debuggen, wenn es etwas ist, das der Kunde tatsächlich installiert / kauft, um die Vollversion irgendwo versteckt zu haben.
Pharaun
4
@ ItayMoav-Malimovka Gib es zu, du hast 'g' benutzt, nur damit du diesen Witz machen kannst.
Andrei
34

Ich habe einmal einen ausführlichen "Versioning Style Guide" für ein großes Projekt von mir geschrieben. Das Projekt ist nicht zustande gekommen, aber der Styleguide ist weiterhin online verfügbar . Es ist meine persönliche Meinung, vielleicht ist es hilfreich (oder inspirierend) für Sie.

Achtung, es ist ein langer Text, der sich mit der Versionierung von Komponenten und der Versionierung von Produkten und dergleichen befasst. Es drückt auch starke Meinungen zu einigen in der OSS-Community beliebten Versionsschemata aus, aber ich habe sie, also drücke ich sie aus. ;-);

Ich bin beispielsweise nicht damit einverstanden, die Subversion-Revisionsnummer zu verwenden. Möglicherweise möchten Sie eine freigegebene Version beibehalten, während Sie die Entwicklung in TRUNK fortsetzen. Daher richten Sie einen Wartungszweig ein - und Ihre Versionsnummerierung geht den Bach runter.

Bearbeiten: Zusammenfassend wird zwischen der Versionierung von Quelldateien, Komponenten und dem Gesamtprodukt unterschieden. Es verwendet ein System der getrennten xy-Versonisierung für Komponenten und das Produkt mit einer guten gegenseitigen Abhängigkeit zwischen den beiden, wodurch die Rückverfolgung, welche Komponentenversion zu welcher Produktversion gehört, trivial ist. Es wird auch darüber gesprochen, wie man mit Alpha / Beta / Release / Patch-Zyklen umgeht, ohne das System zu beschädigen. Eigentlich ist es ein Modus Operandi für den gesamten Entwicklungszyklus, also möchten Sie vielleicht Kirschbaum pflücken. ;-);

Bearbeiten 2: Da genügend Leute meinen Artikel nützlich fanden, um daraus eine "nette Antwort" zu machen, begann ich erneut, an dem Artikel zu arbeiten. PDF- und LaTeX-Versionen sind jetzt verfügbar. Eine vollständige Überarbeitung mit besserer Sprache und erklärenden Grafiken wird folgen, sobald ich die Zeit finde. Vielen Dank für Ihre Stimmen!

DevSolar
quelle
1
Wie GmonC sagte, ist dies ein alter Thread, aber ich habe ihn gefunden, Ihr verknüpftes Dokument gelesen und wollte sagen, gut gemacht. Einige ausgezeichnete Dinge, die zum Nachdenken anregen. Vielen Dank! +1
Carvell Fenton
1
Nachdem ich einige Ihrer Kommentare zu anderen Antworten gelesen hatte, hoffte ich, dass Sie eine Antwort gepostet hatten. Und ich wurde nicht enttäuscht. Schöner Artikel.
Jontyc
31

Lassen Sie sich von Wikipedia inspirieren: "Software-Versionierung"

Eine weitere "neue" und "relativ beliebte" Option ist die semantische Versionierung

Zusammenfassung:

Inkrementieren Sie mit einer Versionsnummer MAJOR.MINOR.PATCH Folgendes:

  1. MAJOR-Version, wenn Sie inkompatible API-Änderungen vornehmen,
  2. MINOR-Version, wenn Sie Funktionen abwärtskompatibel hinzufügen, und
  3. PATCH-Version, wenn Sie abwärtskompatible Fehlerbehebungen vornehmen.

Zusätzliche Beschriftungen für Pre-Release- und Build-Metadaten sind als Erweiterungen des MAJOR.MINOR.PATCH-Formats verfügbar.

scable
quelle
2
@ Ravi - vielleicht, aber es könnte zerstört werden. SO erfordert Reputation zum Bearbeiten. Zumindest eine Zusammenfassung wäre besser für Leute, die diese Frage überfliegen.
Nathan Long
@ Nathan, wenn Sie SO verwenden, können Sie sicherlich den Artikelbearbeitungsverlauf von Wikipedia verwenden.
CMircea
11
@iconiK - Wenn Sie SO verwenden, verstehen Sie sicherlich, dass "Hier ist eine klare, präzise Antwort auf derselben Seite mit anderen Antworten" hilfreicher ist als "Hier ist ein Link zu einer anderen Site, auf der Sie alte Versionen eines Artikels durchsuchen können und vielleicht etwas relevantes finden. "
Nathan Long
11

A B C D

Inkremente: wann
- d : Fehlerbehebungen
- c : Wartung, z. B. Leistungsverbesserung
- b : neue Funktionen
- a : Architekturänderung

Die obligatorische ist die am weitesten links stehende, z. B. wenn beispielsweise eine neue Funktion und ein Fehler behoben wurden, müssen Sie nur b erhöhen .

Alexis Gamarra
quelle
Was sind einige Beispiele für einen architektonischen Wandel?
eaglei22
1
Zum Beispiel eine progressive Migration zu Microservices oder eine Migration zu einer anderen Plattform, die dramatische Änderungen
Alexis Gamarra
9

Aufgrund meiner Erfahrung mit komplexem Abhängigkeitsmanagement auf Unternehmensebene und Release-Versionierung empfehle ich einen Ansatz, den ich gerne als semisemantische Versionierung bezeichne .

Grundsätzlich baut es auf Semantic Versioning 2.0 auf , ist aber nicht ganz so streng.

Semisemantische Versionssegmente:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Primäres Release-Segmentformat:

MARKETTING.MAJOR.MINOR.PATCH

Jedes Segment sollte alphanumerische Zeichen zulassen, für logische inkrementelle Änderungen werden jedoch reine Zahlen empfohlen.

Wie bei SemVer empfehle ich Major-, Minor- und Patch-Komponenten , um Reverse-Kompatibilitätsstufen darzustellen, aber ich empfehle auch, eine Marketing-Komponente voranzustellen . Auf diese Weise können Produktbesitzer, Feature-Epen / Gruppen und geschäftliche Probleme die Hauptkomponente unabhängig von technischen Kompatibilitätsproblemen stoßen.

Im Gegensatz zu anderen Antworten empfehle ich nicht, eine Build-Nummer an das primäre Segment anzuhängen. Fügen Sie stattdessen ein Post-Release-Segment nach einem '+' hinzu (Beispiel: 1.1.0.0 + build.42). SemVer nennt diese Build-Metadaten, aber ich denke, das Post-Release-Segment ist klarer. Dieses Segment eignet sich hervorragend zum Deklarieren der Suffixdaten als nicht mit den Kompatibilitätsinformationen im primären Release-Segment verbunden. Ihren kontinuierlichen Integrations-Builds kann dann die vorherige Versionsnummer zugewiesen werden, an die eine inkrementelle Build-Nummer angehängt wird, die nach jeder primären Version zurückgesetzt wird (Beispiel: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Einige Leute möchten alternativ die svn-Revisionsnummer hier oder das git commit sha einfügen, um die Verknüpfung mit dem Code-Repository zu vereinfachen. Eine andere Möglichkeit besteht darin, das Post-Release-Segment für Hotfixes und Patches zu verwenden. Es kann jedoch sinnvoll sein, eine neue primäre Release-Komponente hinzuzufügen. Es kann immer gelöscht werden, wenn die Patch-Komponente inkrementiert wird, da die Versionen effektiv linksbündig ausgerichtet und sortiert sind.

Zusätzlich zu den Release- und Post-Release-Segmenten möchten Benutzer häufig ein Pre-Release-Segment verwenden , um nahezu stabile Pre-Releases wie Alphas, Betas und Release-Kandidaten anzuzeigen. Der SemVer-Ansatz funktioniert gut, aber ich empfehle, numerische Komponenten von alphanumerischen Klassifikatoren zu trennen (z. B. 1.2.0.0 + alpha.2 oder 1.2.0.0 + RC.2). Normalerweise stoßen Sie das Release-Segment gleichzeitig mit dem Hinzufügen des Post-Release-Segments an und löschen das Pre-Release-Segment, wenn Sie das primäre Release-Segment das nächste Mal anstoßen (Beispiel: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Pre-Release-Segmente werden hinzugefügt, um anzuzeigen, dass die Release-Version verfügbar ist. In der Regel handelt es sich lediglich um einen festen Satz von Funktionen für eingehendere Tests und Freigaben, die sich aufgrund weiterer Commits nicht von Minute zu Minute ändern.

Das Schöne daran, all dies semantisch so definiert zu haben, dass es fast alle Anwendungsfälle abdeckt, ist, dass Sie sie auf standardmäßige Weise analysieren, sortieren, vergleichen und inkrementieren können. Dies ist besonders wichtig, wenn CI-Systeme für komplexe Anwendungen mit vielen kleinen, unabhängig versionierten Komponenten (wie Mikrodiensten) mit jeweils eigenen verwalteten Abhängigkeiten verwendet werden.

Wenn Sie interessiert sind, habe ich einen semisemantischen Parser in Ruby geschrieben . Ich musste dieses Muster nicht nur verwenden, sondern auch andere Apps verwalten können, die es verwendeten.

KarlKFI
quelle
4

"Versionsnummern" sind Sache Ihres internen Versionskontrollsystems. Versionsnummern sind eine andere Sache (und sollten anders sein als KEPT).

Halten Sie sich an ein einfaches MAJOR.MINOR-Release-System (wie v1.27), bei dem MAJOR die Kompatibilitätsstufe ist (Version 2.x ist nicht kompatibel mit Version 1.x oder unterscheidet sich zumindest stark von Version 1.x) und MINOR Ihre Bugfix-Releases oder kleinere Verbesserungen sind . Solange Sie dem XY-Format folgen, können Sie auch andere Systeme wie YEAR.MONTH (2009.12) oder YEAR.RELEASE (2009.3) verwenden. Aber wahrscheinlich bleiben Sie am besten bei MAJOR.MINOR, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.

Verwenden Sie auf keinen Fall etwas, das nicht zum XY-Format passt, da es für Distributionen, Ankündigungswebsites usw. schwierig ist, mit Ihnen zusammenzuarbeiten, und dies allein könnte die Popularität Ihres Projekts ernsthaft beeinträchtigen.

Verwenden Sie Zweige und Tags in Ihrem (vorzugsweise verteilten) Versionskontrollsystem, um bestimmte interne Versionsnummern als MAJORS bzw. MINORS zu kennzeichnen.

Und ja, 1.0 sollte stabil sein. Alle Releases sollten stabil sein, es sei denn, sie sind als Alpha, Beta oder RC gekennzeichnet. Verwenden Sie Alphas für bekannte, fehlerhafte und unvollständige. Betas für bekannt gebrochen. RCs für "Probieren Sie es aus; Sie werden wahrscheinlich Dinge entdecken, die wir verpasst haben". Alles ohne eines davon sollte (im Idealfall natürlich) getestet werden, als gut bekannt bekannt sein, ein aktuelles Handbuch haben usw.

Lee B.
quelle
1
Ich bin damit einverstanden, dass das, was der Benutzer sieht und was Sie erstellen, zwei verschiedene Dinge sind, aber müssen Sie die beiden nicht irgendwie verbinden? Das heißt, Ihre Versions- und Versionsnummern sollten in Beziehung stehen und Sie sollten in der Lage sein, eine Versionsnummer aus einer Versionsnummer zu ermitteln
Jeffrey Cameron
Bei Open Source kümmern wir uns nicht um Build-Nummern. Wir verteilen Quellcode und Builds sind bis zu den Distributionen. Wenn sie einen Fehler in ihrer Version sehen, aber nicht in der Quellversion, haben sie im Build etwas falsch gemacht. Andernfalls ist es der Code für dieses Release-Tag. Tags sind auch in VC sichtbar.
Lee B
2

Es ist heutzutage ziemlich beliebt, nur die Subversion-Revisionsnummer zu verwenden.

mbp
quelle
1
Siehe meine Antwort - Die SVN-Revisionsnummer wird unterbrochen, sobald Sie einen Wartungszweig eingerichtet haben.
DevSolar
3
Die Verwendung der SVN-Revision als TEIL Ihrer Versionsnummer ist sehr verbreitet / beliebt. Die Verwendung nur der SVN-Versionsnummer hat viele Probleme, z. B. was DevSolar hervorhebt.
Rmeador
2

Wenn es in SVN ist, warum nicht die SVN-Versionsnummer verwenden?

Wenn Sie unten rechts auf dieser Webseite nachsehen, sehen Sie die Versionsnummer des Stapelüberlaufs, die die SVN-Versionsnummer ist.

Alan Mullett
quelle
1
Siehe meine Antwort - Die SVN-Revisionsnummer wird unterbrochen, sobald Sie einen Wartungszweig eingerichtet haben.
DevSolar
2

Die Versionierung liegt bei Ihnen. Ich habe 1.0 auf die erste Version gesetzt, von der ich überzeugt war. Vielleicht möchten Sie sie schnell mit anderen Versionen verfolgen, da einige Softwareanbieter 1.0 einen schlechten Ruf verliehen haben.

Sie möchten die Versionsnummer auf irgendeine Weise an den genauen verwendeten Build binden, möchten aber wahrscheinlich, dass sie für Ihre Endbenutzer nett und einfach ist. Erwägen Sie die Verwendung von Standardversionsnummern und die Kennzeichnung des SVN-Repositorys mit der enthaltenen Versionsnummer.

David Thornley
quelle
2

Es ist zwar nett und einfach, nur die Subversion-Versionsnummer zu verwenden, sie entfernt jedoch Informationen aus der Versionsnummer. Benutzer halten dies möglicherweise für eine schlechte Sache.

Ich gehe davon aus, dass Ihre Webanwendung über eine Art Bereitstellungsverfahren verfügt, sodass nicht jede Revision in Subversion tatsächlich veröffentlicht wird. Da es von "außen" (aus Sicht des Benutzers) unmöglich ist zu bestimmen, wann Releases vorgenommen werden und wie viele Revisionen der Code zwischen ihnen durchlaufen wird, werden die Zahlen fast zufällig. Sie werden zunehmen, und ich denke, es ist möglich, eine gewisse Distanz zum Vergleich zweier Revisionen zu vermuten , aber nicht viel.

Klassische Versionsnummern neigen dazu, Releases zu "dramatisieren", so dass Benutzer eine Art Erwartung aufbauen können. Es ist einfacher zu denken "Ich habe Version 1.0, jetzt fügt Version 1.1 dies und das hinzu, das klingt interessant" als zu denken "gestern haben wir SO Revision 2587 ausgeführt, heute ist es 3233, es muss viel besser sein!".

Natürlich kann diese Dramatisierung auch aufgeblasen werden, da Unternehmen Versionsnummern auswählen, die interessanter klingen sollen, als dies durch die tatsächlichen Unterschiede im Produkt motiviert ist.

entspannen
quelle
2

Versionsschema: [Dur]. [Moll]. [Devrel] [Mark]
[Dur]: Inkrementieren, wenn sich die Entwicklung drastisch ändert.
[geringfügig]: Inkrementieren, wenn sich die Entwicklung geringfügig geändert hat.
[devrel]: Inkrementieren, wenn Sie eine Fehlerbehebung haben. Auf Null zurücksetzen, wenn Major ++ oder Minor ++.
[mark]: a, b oder rc: a ist eine Alpha-Version, b ist eine Beta-Version und rc ist ein Release-Kandidat. Beachten Sie, dass Versionen wie 1.3.57a oder 1.3.57b oder 1.3.57rc vor der Version 1.3.57 liegen. Beginnen Sie bei 0.0.0.

Gavriel Feria
quelle
1

Wir haben viel zu viel Zeit damit verbracht, zu entscheiden, wann die Hauptversion erhöht werden soll. Einige Shops würden es selten tun, so dass Sie Veröffentlichungen wie 1.25.3 haben würden, und andere würden es für jede Veröffentlichung tun, die Ihnen 15.0 gibt

Ich hatte es satt und überzeugte alle, dass die Hauptveröffentlichungsnummer nur das Jahr und die Nebenveröffentlichung nur eine sequentielle Veröffentlichung innerhalb des Jahres ist. Die Benutzer schienen es zu mögen und es ist ein Kinderspiel, die nächste Versionsnummer zu finden.

Year.Release.build

  • Jahr = aktuelles Jahr
  • release = Sequenzanzahl der öffentlichen Veröffentlichungen mit neuer Funktionalität - jedes Jahr auf 1 zurücksetzen
  • build = erhöht für Fehlerkorrekturen und interne Releases

BEARBEITEN

** Nun war dies für eine interne App, die kontinuierlich verbessert wurde **

Dies würde wahrscheinlich nicht für kommerzielle Apps funktionieren, bei denen es wichtig ist, Hauptversionen zu unterschiedlichen Jahreszeiten für Marketing- und Finanzzwecke zu haben.

DJ.
quelle
2
... was die erste Veröffentlichung eines neuen Jahres automatisch zu einer "Hauptveröffentlichung" macht, egal wie bedeutend die Änderungen sind. Und Sie können auch nicht innerhalb eines Jahres eine "Haupt" -Veröffentlichung machen ...
DevSolar
1

Der Grund, warum diese Frage besteht, ist, dass wir keinen einzigen vereinbarten Weg für das Konfigurationsmanagement haben.

Die Art und Weise, wie ich die Versionsnummer mache, ist nur eine inkrementelle Ganzzahl von 1. Ich möchte keine mehrteilige Versionsnummer, die ich erklären oder dokumentieren muss. Und ich möchte keine SVN-Rev.-Nummer verwenden, da dies ebenfalls einige Erklärungen erfordert.

Sie benötigen einige Release-Skripte zusätzlich zu SVN, um dies zu erreichen

Pyrolistisch
quelle
0

Ich habe sehr wenig Erfahrung in der Gegend. Folgendes würde ich jedoch tun:

  1. Wählen Sie ein Schema für die Nummerierung von Revisionen und halten Sie sich daran. Seien Sie konsequent.
  2. Jede Versionsänderung sollte eine signifikante Änderung darstellen . Wie klein eine Änderung ist und welche Änderungsstufen sich in der Versionsnummer widerspiegeln, liegt bei Ihnen.

Natürlich können Sie auch einfach die SVN-Revisionsnummer verwenden - wie viele andere vorgeschlagen haben !!!

Ich hoffe das hilft.

Batbrat
quelle
0

Wir verwenden eine einfache Syntax major.minor.julian_date.

Wo;

  • major - Die erste Version ist 1, und wenn wir wichtige neue Funktionen oder Änderungen einführen, die so bedeutend sind, dass sie nicht abwärtskompatibel sind, erhöhen Sie diese Anzahl.
  • Moll - Die wichtigsten Meilensteinveröffentlichungen. Für jeden von der Produktion vorangetriebenen Build erhöht sich diese Anzahl.
  • julian_date - Am Julianischen Tag wurde der Build an die Qualitätssicherung weitergeleitet.

Beispiel für die erste Version, die am 15. Januar an QA gesendet wurde, ist -> 1.0.015.
Beispiel für die erste Version, die am 3. März an die Produktion gesendet wurde, ist -> 1.1.063

Es ist nicht perfekt, aber praktisch, da wir Builds fast täglich zur Qualitätssicherung bringen.

CmdrTallen
quelle
0

Einige gute Infos hier:

Wann müssen Datei- / Baugruppenversionen geändert werden?

Erstens müssen Dateiversionen und Baugruppenversionen nicht miteinander übereinstimmen. Ich empfehle, dass sich die Dateiversionen mit jedem Build ändern. Ändern Sie die Assemblyversionen jedoch nicht bei jedem Build, damit Sie den Unterschied zwischen zwei Versionen derselben Datei erkennen können. Verwenden Sie dazu die Dateiversion. Um zu entscheiden, wann Baugruppenversionen geändert werden sollen, müssen die zu berücksichtigenden Buildtypen erläutert werden: Versand und Nichtversand.

Builds ohne Versand Im Allgemeinen empfehle ich, Baugruppenversionen ohne Versand zwischen Versand-Builds gleich zu halten. Dadurch werden Probleme beim Laden von Assemblys mit starkem Namen aufgrund von Versionsinkongruenzen vermieden. Einige Benutzer bevorzugen die Verwendung von Publisher-Richtlinien, um neue Assemblyversionen für jeden Build umzuleiten. Ich empfehle jedoch dagegen für Builds ohne Versand: Es werden nicht alle Ladeprobleme vermieden. Wenn ein Partner beispielsweise Ihre App x-kopiert, weiß er möglicherweise nicht, wie er die Publisher-Richtlinie installiert. Dann wird Ihre App für sie kaputt gehen, obwohl es auf Ihrem Computer einwandfrei funktioniert.

Wenn es jedoch Fälle gibt, in denen unterschiedliche Anwendungen auf demselben Computer an unterschiedliche Versionen Ihrer Assembly gebunden werden müssen, empfehle ich, diesen Builds unterschiedliche Assemblyversionen zuzuweisen, damit die richtige für jede App verwendet werden kann, ohne LoadFrom / etc. Verwenden zu müssen.

Versand-Builds Ob es eine gute Idee ist, diese Version für Versand-Builds zu ändern, hängt davon ab, wie die Bindung für Endbenutzer funktionieren soll. Möchten Sie, dass diese Builds nebeneinander oder an Ort und Stelle sind? Gibt es viele Änderungen zwischen den beiden Builds? Werden sie einige Kunden brechen? Interessiert es Sie, dass es sie kaputt macht (oder möchten Sie Benutzer dazu zwingen, Ihre wichtigen Updates zu verwenden)? Wenn ja, sollten Sie die Assembly-Version erhöhen. Bedenken Sie jedoch, dass eine zu häufige Ausführung die Festplatte des Benutzers mit veralteten Baugruppen verunreinigen kann.

Wenn Sie Ihre Assembly-Versionen ändern Um fest codierte Versionen auf die neue zu ändern, empfehle ich, eine Variable auf die Version in einer Header-Datei festzulegen und die Hardcodierung in Quellen durch die Variable zu ersetzen. Führen Sie dann während des Builds einen Vorprozessor aus, um die richtige Version einzufügen. Ich empfehle, die Versionen direkt nach dem Versand zu ändern, nicht direkt vor dem Versand, damit aufgrund der Änderung mehr Zeit bleibt, um Fehler zu erkennen.

Gulzar Nazim
quelle
-3

Oder um Ihre 'Gedanken'-Versionsnummer zu verwenden, Komma-Subversion-Nummer. ZB:

1.0.101 // Revision 101, Release

oder 1.0.101-090303 // mit Veröffentlichungsdatum, ich benutze dies

nothrow
quelle