Wann ändern Sie Ihre Haupt- / Neben- / Patch-Versionsnummer?

Mögliches Duplikat:
Welche "Versionsnamenskonvention" verwenden Sie?

Ändern Sie Ihre Haupt- / Neben- / Patch-Versionsnummern direkt vor oder nach der Veröffentlichung?

Beispiel: Sie haben gerade 1.0.0 für die Welt freigegeben (huzzah!). Aber warte, feiere nicht zu viel. 1.1.0 erscheint in sechs Wochen! Sie beheben also einen Fehler und erstellen einen neuen Build. Wie heißt dieser Build? 1.1.0.0 oder 1.0.0.xxxy (wobei xxxy die inkrementierte Build-Nummer von 1.0.0 ist)?

Denken Sie daran, dass Sie möglicherweise 100 Funktionen und Fehler für 1.1.0 haben. Es kann also gut sein, es 1.0.0.xxxy zu nennen, da Sie 1.1.0 nicht näher kennen. Auf der anderen Seite arbeitet möglicherweise ein anderer Entwickler an 2.0.0. In diesem Fall wird Ihr Build möglicherweise besser als 1.1.0.0 und 2.0.0.0 anstatt als 1.0.0.xxxy bzw. 1.0.0.xxxz bezeichnet.

Nachdem Sie Ihre Software veröffentlicht haben, sollte die Versionsnummer sofort erhöht werden.

Warum?

Nehmen wir an, Sie folgen einem Schema wie Semantic Versioning und haben eine Build-Nummer in der Version. Sie könnten also [Major]. [Minor]. [Patch]. [Build] haben. Ich werde den [Major]. [Minor]. [Patch] Teil der Version nennen.

Sie werden während der Entwicklung mehrere Builds erstellen. Jeder Build ist ein Entwicklungsschnappschuss Ihrer nächsten Version. Es ist sinnvoll, für Ihre Entwicklungs- und Release-Builds dieselbe Version zu verwenden. Die Version gibt an, auf welches Release Sie hinarbeiten .

Wenn Sie sich auf die Veröffentlichung vorbereiten und die Software alle Tests besteht, möchten Sie die Software nicht neu erstellen und erneut testen, nur weil Sie die Version aktualisieren mussten. Wenn Sie irgendwann ein Release erstellen, geben Sie an, dass "Build 1.1.0.23" künftig als "Version 1.1.0" bezeichnet werden soll.

Das Inkrement-After-Release-Modell ist auch für die Verzweigung sinnvoll. Angenommen, Sie haben einen Hauptentwicklungszweig und erstellen Wartungszweige für Releases. Sobald Sie Ihren Release-Zweig erstellen, ist Ihr Entwicklungszweig nicht mehr mit der Versionsnummer dieses Releases verknüpft. Der Entwicklungszweig enthält Code, der Teil der nächsten Version ist, daher sollte die Version dies widerspiegeln.

Im Allgemeinen versuche ich, SemVer für interne Versionsnummern zu verwenden. Es ist schön, etwas über ein Release basierend auf der Semantik seiner Versionsnummer wissen zu können.

Während der Entwicklung versuche ich, die Versionsnummern sofort zu ändern (falls möglich) . Manchmal ist es schwer zu wissen, ob die Änderung eine brechende Änderung ist oder nicht (was meine Versionsnummer beeinflusst), daher ist nichts "in Stein gemeißelt".

So sprechen Sie Ihr spezielles Beispiel an:

• Während der Entwicklung wären Vorabversionen 1.0.1-alpha.1, 1.0.1-alpha.2 usw.
• Die endgültige Version des Bugfixes wäre Version 1.0.1.

Allerdings werden die Versionsnummern der öffentlich zugänglichen Produkte häufig vom Marketing festgelegt und sind völlig unterschiedlich. Dies ist außerhalb meiner Kontrolle, also macht es keinen Sinn, sich darüber Gedanken zu machen.

Nehmen wir in den Antworten ABCD an. Wann erhöhen Sie die einzelnen Komponenten?

Dies wird im Wesentlichen durch Ihre Unternehmensrichtlinie bestimmt. Unsere Firmenpolitik ist:

• A - Wesentliche (> 25%) Änderungen oder Ergänzungen der Funktionalität oder der Benutzeroberfläche.
• B - kleine Änderungen oder Ergänzungen in der Funktionalität oder Oberfläche.
• C - kleinere Änderungen, die die Schnittstelle zerstören.
• D - Behebt einen Build, der die Schnittstelle nicht ändert.

In größeren Projekten / Organisationen werden die Haupt- und Nebenversionsnummern von den Marketingabteilungen gesteuert und normalerweise aus Marketinggründen inkrementiert. In meiner Organisation möchten Gruppen jedes Jahr eine Haupt- und eine Nebenversion veröffentlichen. Die Erwartung ist, dass Hauptversionen bedeutende neue Funktionen enthalten und es eine Binärkompatibilität zwischen APIs für alle Versionen mit derselben Hauptversionsnummer gibt. Das Marketing kann sich jedoch dafür entscheiden, eine größere Versionsänderung zu einer kleineren herabzustufen, da versprochene Funktionen nicht geliefert werden oder umgekehrt, um beispielsweise den Froschwettbewerb zu beschleunigen.

Die Haupt- und Neben-Build-Nummern (c und d in abcd) werden normalerweise durch die Entwicklung gesteuert. c ist die Build-Nummer und d wird für Patches in einer bestimmten Version von c verwendet.

In Ihrem Fall ist das Ändern der Haupt- und Nebenversionsnummern weniger relevant als das Sicherstellen, dass die Haupt- und Nebenversionsnummern korrekt sind. In meiner Organisation ändern wir die Haupt- und Nebenbuildnummern im Rahmen des Verzweigungsprozesses in der Quellcodeverwaltung. Die Hauptniederlassung enthält normalerweise die neueste Version, aber Marketing hat möglicherweise noch nicht entschieden, welche Versionsnummer die Veröffentlichung noch haben wird.

Wir versuchen, dem Eclipse-Beispiel zu folgen . Es ist besser zu erklären, als ich es kann, aber effektiv funktioniert es bei uns so:

Wenn Sie 1.0.0.0 freigeben, hängt die Versionsnummer, auf die Sie sich ändern, von der Art der Änderung ab, die Sie vornehmen.

• Eine Version, die sich nicht auf die API auswirkt. Betrachten Sie eine Fehlerbehebung im Hintergrund, durch die die aktuelle API auf die erwartete Weise funktioniert. Sie wird mit 1.0.1 veröffentlicht
• In einer Version, die zur API hinzugefügt wird, aber die vorhandene API nicht ändert, haben Sie möglicherweise eine neue Funktion hinzugefügt, mit der aktuelle Clients nicht mit der neuen Version verglichen werden können. Dies kann auch eine beliebige Anzahl der oben genannten Korrekturen umfassen.
• Ein Release unterbricht die aktuelle API, indem es etwas entfernt und auf eine Weise ändert, die die Vergleichbarkeit mit aktuellen Clients beeinträchtigt. Dies kann auch eine beliebige Anzahl der oben genannten Fehlerbehebungen zur Folge haben.

Die Verwendung des vierten Abschnitts in der Versionsnummer dient dazu, verschiedene Builds in Nuget (der Paketverwaltungslösung, die wir für .net verwenden) zu unterscheiden. Auf diese Weise müssen wir die Caches nicht jedes Mal löschen, wenn wir unsere unveröffentlichte Software aktualisieren müssen.

Es gibt keinen nächsten Build. Auf diesem Ast.

Idealisierte Version unseres Schemas.

Die Versionsidentifikation für jeden Zweig lautet PRETTY_BRANCH_NAME-build und PRETTY_BRANCH_NAME wird bei der Erstellung des Zweigs festgelegt.

Unser Verzweigungsschema (*) lautet wie folgt:

Zweige der obersten Ebene, der PRETTY_BRANCH_NAME jedes dieser Zweige ist ein Codename, wobei die Versionsnummer auf dieser Ebene bedeutungslos ist. Möglicherweise ist ein Schema geplant, das sich jedoch vor der Veröffentlichung ändert.

• ein TNG- Zweig ( die nächste Generation ), in dem langfristige Entwicklungen stattfinden. Oft haben wir es nicht einmal und es hat nie (Release) Unterzweige.

• ein TCG- Zweig ( die aktuelle Generation ), in dem die aktuelle Entwicklung stattfindet. PRETTY_BRANCH_NAME ist ein Codename.

• ein TPG- Zweig ( der vorherigen Generation ). Oft wird hier keine Entwicklung mehr gemacht, aber es kann Aktivität in den Unterzweigen geben.

Eine Unterbranche besteht aus einem Zweig der obersten Ebene (TCG, bei langsamer Migration von TPG), wenn die Betaversion für eine Hauptversion gestartet wird. Der PRETTY_BRANCH_NAME ist so etwas wie "1.3.X" (X ist der Buchstabe, nicht die Ziffer, es bedeutet, dass wir ab hier 1.3 Releases liefern wollen). Das Feedback von der Beta wird hier berücksichtigt, während an der Arbeit für das nächste Haupt-Release gearbeitet wird die TCG-Niederlassung.

Im Idealfall sollte die Freigabe für diesen Zweig eine Momentaufnahme sein, aber wir wissen, dass wir nicht perfekt sind und häufig Änderungen in letzter Minute vornehmen müssen, während andere für die nächste kleinere Freigabe weiterarbeiten können. So werden Unterzweige für die endgültige Stabilisierung erstellt, wobei hübsche Namen die offizielle Versionsnummer sind (zu diesem Zeitpunkt möchte auch das Marketing dies nicht ändern), wie "1.3", "1.3.1" aus dem Zweig "1.3.X". Der letzte Build auf jedem ist das Release.

Wenn wir eine vierte Ebene hätten, wären die Namen der Unterzweige "1.3.0.X" gewesen, von denen wir Unterzweige "1.3.0.0" "1.3.0.1" gehabt hätten.

(*) Auf der Release-Ebene. Auf diesen können sich jeweils Projektunterbranchen befinden.

Wenn Sie Software verkaufen, haben Sie jedes Mal eine neue Hauptversion, wenn Verkauf / Marketing einen größeren Bonus verdienen müssen :-).

Wenn Sie die Kontrolle haben, dann:

1. Hauptversionen, wenn:

   • Es gibt einige Inkompatibilitäten mit der vorherigen Version, die eine Konvertierung usw. von Python 2 nach Python 3 erfordert.

   • Es gibt eine ganze Menge neuer Funktionen.

2. Kleinere Releases für kleine Änderungen in der Funktionalität.

3. Patch-Release für Bugfixes.