Wie mache ich Versionsnummern?

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!

[ 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

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.

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!

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.

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 .

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.

"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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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