Ermöglicht die semantische Versionierung 4 Komponenten in Versionsnummern?

Alle Beispiele für die semantische Versionierung, die ich gesehen habe, zeigen 3 verwendete Komponenten. Maximal 2 Punktzeichen. Bei verwenden $DAYJOBwir 4 Komponenten in unseren Versionsnummern:

5.0.1.2

Ermöglicht die semantische Versionierung dies?

Und als übergeordnete und fragwürdigere Nebenfrage, spielt es überhaupt eine Rolle? Ich begann zu denken, dass es eine gute Idee sein könnte, die semantische Versionierung zu erzwingen, aber letztendlich überschreiben Entitäten wie PCI sie.

Ich hätte meinen PCI-Kommentar präzisieren sollen. Das Problem ist, dass Audits und deren Kosteneinfluss bei Änderungen der Haupt- und Nebenkomponenten nicht unbedingt eine echte Neuerung darstellen. Wenn zum Beispiel eine Funktion in Bezug auf Zahlungen eingeführt wird, wird die untergeordnete Nummer für PCI erhöht. Wenn wir jedoch eine brandneue Funktion hinzufügen, die sich auf etwas in der Benutzeroberfläche bezieht, ist dies nicht der Fall. Nur der Patch ändert sich. In diesem Fall haben wir als Entwickler also kein wirkliches Mitspracherecht, da jemand anderes diese Entscheidungen trifft.

Es hört sich so an, als würden Sie normale Konventionen umgehen, nur um Prozess-Overhead / Audits zu vermeiden. Das ... kommt mir besorgniserregend vor.

Effektiv macht eine zusätzliche Versionsnummer (Ihre minderjährigen PCI digit) etwas absichtlich , um Ihre Funktion / Minor - Versionsnummern zu bewegen , was Sie tun sichern einen Platz, um nicht mehr ausgelöst , Ihre internen Kriterien Prüfung.

Um Ihre Frage zur semantischen Versionierung zu beantworten, heißt es in der Spezifikation zur semantischen Versionierung :

Wenn Sie eine Versionsnummer MAJOR.MINOR.PATCH haben, erhöhen Sie Folgendes:

• MAJOR-Version, wenn Sie inkompatible API-Änderungen vornehmen,
• MINOR-Version, wenn Sie Funktionen abwärtskompatibel hinzufügen, und
• PATCH-Version, wenn Sie abwärtskompatible Fehlerbehebungen vornehmen.
• Zusätzliche Labels für Vorabversionen und Build-Metadaten sind als Erweiterung des MAJOR.MINOR.PATCH-Formats verfügbar .

Betonung meiner.

Die Frage ist also, ob Sie das vierte Zeichen für Vorabversions- / Build-Metadaten verwenden. Oder handelt es sich im Grunde genommen um eine andere Versionsangabe, die Sie veröffentlichen?

Wenn "Ja", dann erlaubt die Spezifikation der semantischen Versionierung dies. Wenn "nein", folgen Sie der semantischen Versionierung technisch nicht.

Und als übergeordnete und fragwürdigere Nebenfrage, spielt es überhaupt eine Rolle?

Ob Sie sich strikt daran halten wollen oder nicht, müssen Sie und Ihr Team entscheiden. Der Zweck der semantischen Versionierung besteht darin, die API-Kompatibilität zu verbessern:

Fehlerkorrekturen, die sich nicht auf die API auswirken, erhöhen die Patch-Version, abwärtskompatible API-Ergänzungen / -Änderungen erhöhen die Nebenversion und abwärts inkompatible API-Änderungen erhöhen die Hauptversion.

Ich nenne dieses System "Semantic Versioning". In diesem Schema geben die Versionsnummern und die Art und Weise, wie sie sich ändern, Auskunft über den zugrunde liegenden Code und darüber, was von einer Version zur nächsten geändert wurde.

Mit diesem System wird klarer, wenn die Versionsverwaltung nachgeschaltete Benutzer der API betrifft.

Solange Ihre API ähnlich klar ist, ist es keine große Sache, wie Sie sich entscheiden. Semantische Versionierung ist einfach unkompliziert, zum Beispiel, wenn ich 3.4.2 verwende und ein Upgrade auf 3.4.10 durchführen muss. Ich weiß, dass ich das tun kann, ohne etwas zu beschädigen. Wenn die neue Version 3.5.1 ist, weiß ich, dass sie abwärtskompatibel ist. Und ich weiß, dass Version 4.0.1 eine bahnbrechende Änderung sein würde.

Das ist alles ein Teil dessen, was die Versionsnummern bedeuten.

@enderland Ja im Grunde. MAJOR (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD. Grundsätzlich dürfen wir nur die 3. und 4. Komponente ändern, ohne dass PCI (und anschließend die PCI-Overlords im Unternehmen) involviert sind. Für mich scheint dies ein wenig erfunden zu sein. Ich bin nicht sicher, ob sie in der Art und Weise gerechtfertigt sind, wie sie die Versionsnummer verwalten, aber ich weiß nicht genug über PCI und den Prüfprozess, um etwas anderes zu sagen.

Ok, das ist in Ordnung. Sie haben ein System, das für Sie arbeitet und Ihren Bedürfnissen entspricht. Darum geht es bei der Versionierung.

Wenn Ihre API privat ist (nur intern ausgerichtet), spielt es keine Rolle, wie Sie die Version verwenden, solange dies für Sie und alle Benutzer sinnvoll ist. Wenn Sie viele andere Benutzer Ihrer API haben, die wissen möchten, was diese Version bedeutet, ist die Versionsverwaltung in einem Standardformat von Bedeutung.

Ein willkürliches Versionssystem wird Leute verwirren, die an andere Systeme wie die semantische Versionierung gewöhnt sind. Aber wenn niemand Ihr Versionsverwaltungssystem wirklich benutzt, außer den Leuten, die es erstellen - ist das eigentlich egal.

In der aktuellen Version von Semantic Versioning, 2.0.0 , No. Es gibt eine Anforderung, die die Version als die Form XYZ definiert, wobei X, Y und Z nicht negative Ganzzahlen sind, die keine führenden Nullen enthalten:

Eine normale Versionsnummer MUSS die Form XYZ haben, wobei X, Y und Z nicht negative ganze Zahlen sind und KEINE führenden Nullen enthalten dürfen. X ist die Hauptversion, Y ist die Nebenversion und Z ist die Patch-Version. Jedes Element muss numerisch erhöht werden. Zum Beispiel: 1.9.0 -> 1.10.0 -> 1.11.0.

Die Möglichkeit, Metadaten hinzuzufügen, ist jedoch für Folgendes zulässig:

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.

Zu beachten ist jedoch, dass die semantische Versionierung speziell für Software gedacht ist, die eine öffentliche API deklariert:

Software, die Semantic Versioning verwendet, MUSS eine öffentliche API deklarieren. Diese API kann im Code selbst deklariert sein oder nur in der Dokumentation vorhanden sein. Wie auch immer es getan wird, es sollte präzise und umfassend sein.

Dies unterstützt in der Regel die Entwicklung von Bibliotheken oder Diensten und nicht auf Anwendungsebene.

Es ist wichtig zu berücksichtigen, welche Bedeutung Ihre Versionsnummern sowohl für den internen als auch für den externen Gebrauch haben. Versionen sind nur Bezeichner, mit denen Sie zu zwei verschiedenen Zeitpunkten über Unterschiede in der Software sprechen können. Die semantische Versionierung ist eine Methode, mit der Sie Regeln festlegen können. Wenn Sie also wissen, dass eine Anwendung die semantische Versionierung verwendet, können Sie den Aufwand für die Aktualisierung Ihrer Pakete einfacher bestimmen. Es mag gut sein, einem gemeinsamen Standard zu folgen, aber wenn Sie dies aus irgendeinem Grund nicht können, sollte es auch ausreichen, die Regeln für Ihre Benutzer zu dokumentieren.