Was bedeuten Update-Versionen wirklich?

Viele Software-Updates folgen dem Schema von v0.1 bis v0.2 bis v2.6.5.6 . Was bedeuten diese "Updates" für Software wirklich? Gibt es einen Industriestandard, der immer eingehalten wird, oder erhöhen Programmierer die Aktualisierungsrate oder fügen weitere Dezimalstellen hinzu?

Wie Shaun sagte, gibt es nicht wirklich einen Standard. Einige Unternehmen haben bessere Versionspraktiken als andere (ich habe mich mit Anbietern befasst, die Hauptversionsnummern überspringen, und andere, die mehrere Releases später auf demselben xy stecken).

Trotzdem hat der Erfinder von Gravatars und Mitbegründer von GitHub ( Tom Preston-Werner ) ein Dokument für ' Semantic Versioning ' verfasst, das mehr als eine Lektüre wert ist.

Hier ist die Ausnahme des Intro:

Als Lösung für dieses Problem schlage ich einen einfachen Satz von Regeln und Anforderungen vor, die vorschreiben, wie Versionsnummern zugewiesen und inkrementiert werden. Damit dieses System funktioniert, müssen Sie zuerst eine öffentliche API deklarieren. Dies kann aus Dokumentation bestehen oder durch den Code selbst erzwungen werden. Unabhängig davon ist es wichtig, dass diese API klar und präzise ist. Sobald Sie Ihre öffentliche API identifiziert haben, teilen Sie Änderungen mit, wobei Ihre Versionsnummer in bestimmten Schritten geändert wird. Betrachten Sie ein Versionsformat von XYZ (Major.Minor.Patch). 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 4 Ziffern ist es normalerweise MajorV.MinorV.PatchNum.BuildNum, zumindest dort, wo ich arbeite.

Ich persönlich bevorzuge das Ubuntu-Versionsschema - macht das Leben so viel einfacher.

Die kurze Version ist, dass es keinen Standard gibt und Unternehmen tun, was sie wollen. Je mehr Zahlen Sie haben, desto geringer ist im Wesentlichen die Anzahl der Änderungen, die jede Zahl darstellt. In der Regel wird mindestens die Version xy angezeigt, in der xa-Änderung in x für Hauptversionen (wichtige Erweiterungen / Feature-Rollouts) und y für Nebenversionen (wichtige Optimierungen oder Fehlerkorrekturen) steht. Mehr Dezimalstellen nach diesen beiden können für ein Unternehmen intern unterschiedliche Bedeutungen haben, obwohl sich diese oft um kleinere Inhaltserstellungen oder Patches drehen, die schnellere und kleinere Korrekturen darstellen.

Wikipedia hat einen Artikel , der dies ausführlicher behandelt.

Der Zweck von Versionsnummern besteht darin, eine Referenz für Problemberichte bereitzustellen. Die einzige Voraussetzung ist, dass jede Version eine eindeutige Versionsnummer hat. Einige Zahlen werden vom Marketing bestimmt - größere ganze Zahlen sind einfacher zu verkaufen, und Potenzzahlen wie 10 (römische Zahl X) sind wirklich eingängig. Einige Leute verwenden eine Variation der semantischen Versionierung:

MAJOR.MINOR.MICRO.BUILD

• Wichtige Schritte: Inkompatible Änderungen oder vollständige Neugestaltung der Benutzeroberfläche
• Kleinere Schritte: Neue Funktionen hinzugefügt, kompatibel mit früheren Versionen mit derselben Hauptversionsnummer
• Mikroschritte: Fehlerbehebung
• Build-Nummer: Wird vom Compiler generiert oder aus der Versionskontrolle abgerufen

Viele Gruppen lassen die BUILD-Nummer in ihren Releases fallen. Dies ist normalerweise nur zwischen Test- und Entwicklungsgruppen sinnvoll.

Einige Gruppen fügen zusätzliche Semantiken hinzu, z. B. ungeradzahlige MINOR-Inkremente für experimentelle Builds und geradzahlige MINOR-Inkremente für Produktionsversionen ( Linux-Kernel verwendet diesen Ansatz).

Unterm Strich gibt es keinen Standard, außer dass neuere Versionen höhere Versionsnummern verwenden und jede Versionsnummer eindeutig ist.