Warum ist build.number ein "Missbrauch" der semantischen Versionierung?

Ich war eine vorgeschlagene Build - System (Gradle / Artifactory / Jenkins / Chef) zu einem unserer leitenden Architekten erklären, und er machte mir einen Kommentar , dass ich irgendwie nicht zustimmen, aber ich bin nicht erfahren genug , um wirklich Wiegen am.

In diesem Projekt wird eine Java-Bibliothek (JAR) als Artefakt erstellt, die von anderen Teams wiederverwendet werden kann. Für die Versionierung möchte ich den semantischen Ansatz von:

<major>.<minor>.<patch>

Wobei patchauf Bug- / Notfall-Fixes, minorauf abwärtskompatible Releases und majorauf massive Überarbeitungen der API und / oder auf abwärts inkompatible Änderungen hingewiesen wird.

Was die Lieferung betrifft, möchte ich Folgendes: Ein Entwickler schreibt einen Code fest. Dies löst einen Build für eine QA / TEST-Umgebung aus. Einige Tests werden ausgeführt (einige automatisiert, einige manuell). Wenn alle Tests bestanden sind, veröffentlicht ein Produktions-Build die JAR für unser internes Repo. Zu diesem Zeitpunkt sollte die JAR-Datei ordnungsgemäß versioniert sein. Meiner Meinung nach sollte build.numberdie von unserem CI-Tool automatisch generierte und bereitgestellte JAR-Datei als Patch-Nummer verwendet werden.

Somit wäre die Versionierung tatsächlich:

<major>.<minor>.<build.number>

Auch hier wird wo build.numbervom CI-Tool zur Verfügung gestellt.

Der Architekt lehnte dies mit der Begründung ab, die Verwendung der CI-Build-Nummer sei ein "Missbrauch" der semantischen Versionierung.

Meine Frage ist: Ist das richtig und wenn ja, warum? Und wenn nicht, warum nicht?

— Herpylderp
quelle

Antworten:

Ihre Build-Nummer wird nicht auf 0 zurückgesetzt, wenn sich die Anzahl der Neben- und Hauptversionen erhöht. Dies verstößt gegen die Abschnitte 7 und 8 der Spezifikationen :

Die Nebenversion Y (xYz | x> 0) MUSS inkrementiert werden, wenn neue, abwärtskompatible Funktionen in die öffentliche API eingeführt werden. Es MUSS inkrementiert werden, wenn eine öffentliche API-Funktionalität als veraltet markiert ist. Es kann inkrementiert werden, wenn im privaten Code wesentliche neue Funktionen oder Verbesserungen eingeführt werden. Es kann Patch-Level-Änderungen enthalten. Die Patch-Version MUSS auf 0 zurückgesetzt werden, wenn die Nebenversion erhöht wird.

Die Hauptversion X (Xyz | X> 0) MUSS inkrementiert werden, wenn rückwärts inkompatible Änderungen an der öffentlichen API vorgenommen werden. Es kann kleinere und Patch-Level-Änderungen enthalten. Patch und Nebenversion MÜSSEN auf 0 zurückgesetzt werden, wenn die Hauptversion erhöht wird.

Daher müssen Versionsnummern (Major, Minor, Patch) manuell angegeben werden, da diese verwendet werden, um Ihre Benutzer über Änderungen an einer Stelle zu informieren, ohne dass sie sich Ihr Changelog oder ein anderes Dokument ansehen müssen.

Wenn Sie Ihre Build-Nummer einfügen möchten, können Sie sie nach a +(Abschnitt 10) anhängen :

Build-Metadaten KÖNNEN durch Anhängen eines Pluszeichens und einer Reihe von durch Punkte getrennten Bezeichnern unmittelbar nach dem Patch oder der Vorabversion gekennzeichnet werden. Bezeichner MÜSSEN nur aus ASCII-Alphanumerik und Bindestrich [0-9A-Za-z-] bestehen. Bezeichner DÜRFEN NICHT leer sein. Build-Metadaten MÜSSEN bei der Bestimmung der Versionsrangfolge ignoriert werden. Somit haben zwei Versionen, die sich nur in den Build-Metadaten unterscheiden, die gleiche Priorität. Beispiele: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

— Residuum
quelle

Schnelles Follow-up @Residuum (und BTW +1 für die Antwort): Sollen die Versionsnummern dann immer manuell abgeleitet werden? Wenn nicht, welche Tools könnten anstelle von CI / Build-Nummer verwendet werden?

— Herpylderp

@herpylderp überhaupt nicht, Tom Preston-Werners "spec" ist nur seine Meinung, viele andere Unternehmen haben unterschiedliche (im Allgemeinen sehr ähnliche) Standards. In den meisten Fällen ist eine automatisch generierte Nummer Bestandteil der Version. Es ist sinnvoll, die CI-Build-Nummer zu verwenden.

— gbjbaanb

Sie können das CI-Tool weiterhin verwenden, wenn Sie mit dem Tool Arithmetik für Build-Nummern ausführen können. Unabhängig davon, welchen Build Sie als Haupt- oder Nebenversions-Upgrade veröffentlichen, geben Sie diese Build-Nummer in einen Ausdruck für die Versionszeichenfolge ein, die von der aktuellen CI-Build-Nummer abgezogen wird. Voila, Sie haben gerade Ihre Build-Nummer für die neue Version auf Null zurückgesetzt, ohne Ihre Build-Nummer tatsächlich zurückzusetzen.

— KeithS

Ich verwende nur [major]. [Minor]. [Revision]. [SVN-Version] für DLLs und [major]. [Minor]. [SVN-Version] für Installer. Die CI-Build-Nummer ist nur für den internen Gebrauch bestimmt, um anzuzeigen, wo ein fehlgeschlagener Build nach einer Änderung an der CI-Umgebung (Installation eines Schlüsselzertifikats, Hinzufügen gemeinsamer Bibliotheken zum GAC usw.) möglicherweise auf derselben Codebasis erneut ausgeführt wurde.

— KeithS

@gbjbaanb et al .: In jeder Diskussion über "semantische Versionierung", an der ich beteiligt war, war die Definition von semver.org das Thema. Durchsuchen Sie das Web nach "semantischer Versionierung", und zumindest auf der ersten Seite finden Sie Vor- und Nachteile der Definition von semver.org . Es steht Ihnen frei, Ihre eigenen Versionsschemata zu verwenden, aber nennen Sie es nicht semantische Versionierung, da dieser Begriff klar definiert ist.

— Residuum

Ein Grund dafür ist, dass der Patch möglicherweise mehrere Builds erfordert. Wenn Sie also Version 5.7 haben und ihn auf 5.7.1 patchen möchten, aber Ihre ersten 2 Bugfixes nicht erstellt werden können, wenn sie an das CI-System gesendet werden, werden Sie es sein bei 5.7.3 bevor du deinen ersten Patch veröffentlicht hast!

Die Antwort ist, einfach 4 Ziffern zu verwenden (wie es bei Microsoft-Systemen der Fall ist). Die vierte ist eine Build-Nummer und wird "nur zu Informationszwecken" verwendet. Im Allgemeinen geben die Benutzer die Versionsnummer des Repositorys an (wenn sie SVN oder TFS oder ähnliches verwenden). Dies ist sehr hilfreich, da Sie überprüfen können, mit welchem genauen Commit die Binärdateien erstellt wurden. Wenn Sie so etwas nicht haben, ist die CI-Build-Nummer eine vernünftige Annäherung (da Sie hoffen, Ihr CI-System kann sich die Build-Nummern merken und sie mit dem Repo-Verlauf verknüpfen, aber Sie sind nicht auf das CI angewiesen System erinnert sich an sie - Sie können niemals alte Builds löschen).

Zu beachten ist, dass das Microsoft-Schema für die Versionsverwaltung die dritte Position für Build-Nummern verwendet. Chrome verwendet nur eine Nummer. Ubuntu verwendet das Datum. Es gibt keinen "Standard" , außer dass alle Zahlen erhöht werden müssen.

— gbjbaanb
quelle

Obwohl es keinen Standard gibt, der universell verwendet oder durchgesetzt wird, scheint die Frage speziell nach der semantischen Versionierung zu sein, die eine Spezifikation hat.

— Doval

Sogar das ist in der Praxis problematisch , zum Beispiel verwendet die NuGet-Versionierung von Microsoft Semver in einer fehlerhaften Weise (unter Verwendung des Prerelease-Stils für Build-Nummern), und Ruby verwendet major.minor.teeny.patch . Wie auch immer, da die Build-Nummer Teil des Semvers sein kann, sprach der Architekt mit Sh (obwohl es zugegebenermaßen + Build sein sollte, nicht an der 3. Position).

— Gbjbaanb

Die SemVer 2.0-Spezifikation stammt aus dem Jahr 2013 und die 1.0-Spezifikation stammt aus dem Jahr 2012, soweit ich das beurteilen kann. Es ist wahrscheinlich, dass NuGet und Ruby ihr eigenes Ding gemacht haben, bevor die Spezifikation erschien. Es ist nicht so, dass die SemVer-Spezifikation neu ist. es wird lediglich formalisiert, was die Leute bereits getan haben, damit wir uns endlich alle auf einen Weg einigen können, anstatt auf ein Dutzend Variationen.

— Doval

msgstr "Sie haben Version 5.7 und möchten es auf 5.7.1 patchen, aber Ihre ersten 2 Bugfixes können nicht erstellt werden, wenn sie an das CI - System gesendet werden. Dann sind Sie bei 5.7.3, bevor Sie Ihren ersten Patch veröffentlicht haben ! " ok aber na und Ich kann mich an nichts erinnern, was besagt, dass die Zahlen nicht überspringen dürfen.

— Andy