Generell sind Versionschemata lediglich Konventionen.
Es gibt im wesentlichen zwei Konventionen für Versionsnummern.
Einmal die traditionelle, die einfach ein paar Nummern durch Punkte voneinander getrennt, hochzählt.
Und neuerdings die "semantische Versionierung".
Die traditionelle Versionierung geht auf eine Eigenschaft der Toolchain für C- Programme zurück.
Diese klassische Toolchain für schlichte C- Programme besteht aus einem Preprocessor, einem Compiler und einem Linker.
Ein Hallo-Welt C-Programm braucht lediglich einen Compiler. Man compiliert den Sourcecode einmal, und es wird ein lauffähiges Binärprogramm ausgespuckt.
Werden die Programme komplexer, verteilt sich der Quellcode aber auf viele Dateien. Damit war die Stunde des Präprozessors gekommen. Man führte include- Statements und IFDEF Makros ein.
Der Quellcode musste von da an erst durch den Präprozessor geschickt werden. Der hat die Aufgabe aus der einen Quellcodedatei einen Quellcode zu erzeugen, den der Compiler auch übersetzen konnte. Dazu löste er anfangs nur die zwei genannten Statements auf. Stößt er dabei auf ein include irgendEineQuellcodeDatei-Statement, so wird genau diese Zeile durch den gesamten Inhalt dieser irgendEineQuellcodeDatei ersetzt. Stößt der Präprozssor auf ein IFDEF so hat er zu entscheiden, welche Quellcodedatei an dieser Stelle für das gesamte IFDEF Konstrukt einzusetzen ist.
Man hatte Modularisierung geschaffen.
Aber die Dinge wurden komplexer, und hören nicht auf, immer komplexer zu werden. Jetzt musste ein MAKEFILE her. Dort wurden ebenfalls viele für den Compiler vorbereitende Jobs erledigt. Und eine vernünftige Versionierung musste mit eingebaut werden. Die Toolchain wuchs und wucherte. Versionierung war unabdingbar geworden.
Man wollte ja nicht nur den unüberschaubaren Wust an Quellcodedateien im Griff haben, sondern auch Fehler in vorhergehenden Versionen bereinigen können. Also wurden Code- Versionierungs- Systeme programmiert. Das erst hies auch genau so: cvs (== CodeVersioningSystem). Heute gibt es davon einige. Um nur die heutzutage unter Linux gebräuchlichsten zu nennen: git, von Linus Torwalds stammend, und hg, auch Mercurial genannt (HG ist das chemische Zeichen für Quecksilber, was auf Englisch "mercury" heißt).
Programmiert man einfach so rum, schreibt man zuerst eine Reihe von Fehlern, dem man dann mühsam in halbwegs funktionierenden Code umarbeitet, um dann letztlich irgendwann eine unendliche Serie von Hilfscode zu schreiben, der nichts anderes tut, als mögliche Fehler abzufangen.
Das ist für egal welche Programmier- oder Scriptsprache schon immer fundamental wahr und bleibt auch wahr für alle Zeiten.
Man führte also die (numerische) Versionierung ein.
Dabei galt im herkömmlichen Versionierungsschema der Grundsatz, dass man ein Zahlen, getrennt durch einen buchstäblichen Punkt, verwendet. Also sowas wie 3.45.6789 (Den grammatisch notwendigen Punkt vor dieser öffnenden Klammer reiche ich der Klarheit halber erst hier nach:).
Aber nochmal: DAS IST EINE KONVENTION! Es ist keine Eigenschaft des Quellcodes, der Toolchain oder eine für die Funktionalität eines Programmes notwendige Eigenschaft. Es ist eine Konvention um die mühsame Fehlerproduktion des Programmierens zu erleichtern.
Man schreibt einfach Version=x.y.z in eine Quellcodedatei. Ändert man diese Zeile später zu Version=x.y.z+1, erkennt die Toolchain eine neue Version.
Das ist alles.
Implizit können moderne IDE's damit dann sogar automatisch Backups machen. (IntegratedDevelopmentEnvironment == ein "Oberflächenfensterchen, in dem alle wesentliche Programmierertools verfügbar sind. Pluggable. Eh klar.)
Man ging schnell dazu über dem Versionsschema 'x.y.z' noch eine weitere durch einen Punkt getrennte Zahl anzufügen. Die Versionsnummer 2.3.4.9876 besagte von nun an, dass die Programmierergenossen bei der Version 2.3.4 sage und schreibe 9875 Fehlversuche hatten. Erst im 9876. Versuch gelang es, den Schrott halbwegs lauffähig zu kompilieren.
Microsoft hält auch heute noch eisern an diesem Versionierungsschema mit vier durch Punkte getrennte Zahlen fest.
Im Rest der Digitalwelt finden alle möglichen und unmöglichen Varianten der Versionierung.
Diese Dinge haben sich ja rein historisch so entwickelt. Völlig frei von technischen Notwendigkeiten oder impliziten Diktaten.
Es war nur sehr bequem für die Versionierung Zahlen getrennt durch einen Punkt zu nehmen.
Die Bedeutung der Versionsnummer ist ebenfalls historisch gewachsen.
Es ist ebenfalls eine Konvention eine Versionsnumer wie 1.2.3.4 wie folgt zu lesen:
1 ist die Hauptversion. Die kann das (Pardon: sollte können), was die Lügeting®™- Abteilung verspricht.
Die 2 steht für die Nebenversionsnummer. Da wurden dann entweder ein paar kleine Features hinzugefügt, oder derbe Fehler ausgemerzt. Aber mit leichten Änderungen ist das dennoch im Wesentlichen die Hauptversion.
Die 3 ist das sogenannte Patchlevel. Der Patch, das englische Wort für "Flicken" beschreibt ziemlich gut, was wirklich gemeint ist: Das Flicken von Programmen. Fehlerhafter Code in einem Programm oder Sicherheitslöcher werden an Ort und Stelle mit einem Stück Software überbügelt, ein besserer Fleckchen Code- Stoff wir halt auf das Codehemd an der Stelle reingenäht, an der das Loch auftrat.
Die 4 bezeichnet, wie schon ausgeführt, die Anzahl der meist vergeblichen Versuche, Flicken zu kreieren.
Aber das ist -nochmal- einfach eine Konvention.
Nur wurde die halt durch massenhaften Gebrauch zum Quasigesetz.
Es gibt -nochmal- keine technische Notwendigkeit für diese Nummern.
Sonst wäre ja auch ein Sprung von 42.3 auf 15.x kaum möglich.
Der Programmierer kann völlig frei irgendwelche Versionierungsschemata verwenden.
Und er kann beliebig Versionsnummern polluieren.
Moderne Quellcode Systeme können damit (fast) beliebig umgehen.
Die "semantische Versionierung" zeigt genau das ja deutlich. Überall gibt es nun Versionsnummern die irgendwelche Nichtzahlen enthalten. Auch bei openSUSE.
Man verwendet nun gerne das Datum der Programmierung zur Verwaltung.
Versionierung ist weder zwingend, noch logisch, noch konsistent.
Sie ist ein Schema das die Verwaltung von Programmen für den Programmierer vereinfacht.
Es sind Zeichen -nicht Zahlen- , die dem Programmierteams die Arbeit erleichtern.
Sie haben darüberhinaus keinerlei Bedeutung.
Damit aber dann doch enorme Bedeutung für alle Distris.
Denn die stehen ja letztlich auch in der Toolchain zwischen Programmier(teams) und User.
Du kannst auch ein Verisionsschema wie saudoofesProgramm.wasnochimmernichttut.obwohliches-schon.vierzehntausendmal+17.versucht.habe verwenden. Konfiguriere dir deine Toolchain einfach entsprechend.
Das ist ganz einfach: Du musst nur die Regeln festlegen, wie sich die jeweiligen Zeichenketten zwischen den Versionen wann ändern.
Und das dann natürlich deinen Tools auch beibringen..
Und ja: du kannst sogar auf die Punkte verzichten, wenn du deine Regeln wirklich clever festlegst.
Bei Versionsnummern hat kein einziges Zeichen eine Bedeutung. Die entsteht erst durch Konvention.
Der Begriff "LTS" (LongTermSupport) ist auch nur ein Papperl, das man einer Version anhängt.
Kann man machen, kann man aber auch lassen.
Und dieses Papperl verwenden nicht alle Software- Her-oder-Bereitsteller.
Bei openSUSE gibt es sowas nicht.
Jedenfalls solange du es nicht selbst auf die Beine stellst.
Das alte Evergreen- Team hat ja kapituliert.