Lifetime Politik bei OpenSUSE

Hinweis: In dem Thema Lifetime Politik bei OpenSUSE gibt es 39 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • 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.

  • Das ist ein umfangreicher Exkurs zum Thema "Versionierung". Das hat viel Diskussionspotential; ich selbst bin da sicher nicht der Profi. Ich halte allerdings grundsätzlich die Versionierung mit den Nummerblöcken und Punkten nach dem Schema xx.xx.xx.(xx) für hilfreich. Wenn diese Art der Versionierung der Konvention folgt und -ich nenne es mal bewusst naiv- "ehrlich" ist, dann kann ich als User zumindest grob sehen, wie lange an einer Software schon entwickelt wurde. Ich würde dann z.B. bei zwei Softwareprodukten, die denselben Zweck haben, die mit der höheren Nummer bevorzugen.....- was wiederum ein Trugschluss sein kann, da dies ja nicht zwingend etwas über die Qualität aussagt. Schwierig schwierig.... Bei Benennungen wie "Windows 95" weiß ich nur, dass diese Software wahrscheinlich 1995 erschienen ist und bei "Windows NT", dass es eine neue Technologie darstellen soll. Wenn man schon dabei ist, dann kann man auch "Tiger" oder "Snow Leopard" sagen.... oder wie wär's mit "treuer Hund" oder "agiles Schwein".... :D
    Schließlich hat sich SUSE offenbar von Douglas Adams inspirieren lassen und nach den 13.x- Versionen als nächstes die 42.x erscheinen lassen, wobei hier ja wegen der Aufspaltung in die beiden Forks "Leap" und "Tumbleweed" ein großer Einschnitt ist. Ich persönlich brauchte seinerzeit länger, um nachzuvollziehen, was da los ist (weil ich mich lange Zeit nicht mehr mit SUSE beschäftigt hatte). Dass die kommende Version wieder dem alten Schema folgt und 15.x heißt, finde ich gut.


    Trotz der ganzen Ausführungen bleibt mir die Lösung des SUSE Rätsels aber leider immer noch verborgen. Hier nochmal das SUSE-Zitat:


    Auf welche Versionen gibt es nun einen Unterstützungszeitraum von mindestens 36 Monaten und auf welche Versionen einen Unterstützungszeitraum von 18 Monaten?


    Wobei mir die Logistik innerhalb der Unterversionen, wie oben beschrieben, auch nicht klar ist.

    Für den Inhalt des Beitrages 120527 haftet ausdrücklich der jeweilige Autor: Suse-Paul

  • Auf welche Versionen gibt es nun einen Unterstützungszeitraum von mindestens 36 Monaten und auf welche Versionen einen Unterstützungszeitraum von 18 Monaten?

    Du hast es doch zitiert und es ist - eigentlich - völlig klar.


    Prinzipiell wird also Leap 15 für 35 Monate unterstützt. Das findet statt in Form der 15.0/15.1/15.2 (oder 15.1/15.2/15.3), die ihrerseits jeweils für ca 18 Monate unterstützt werden.
    3x 18 Monat ergeben 35 weil sich die 18 jeweils deutlich überlappen.


    Also eine 15 wird es so direkt nicht geben. Die erste Release aus der 15er-Hauptversion ist die 15.0 ...


    Schau in die Vergangenheit:


    die Hauptversion 42 gab es nur in Form der 41.1/42.2/42.3 niemals als '42'


    Ein lebensnahes Beispiel:


    Wenn du in der Kneipe deiner Wahl eine Cola bestellst kriegst du keine Cola sondern eine CocaCola/PepsiCola/AldiCola/SonstwasCola


    Leap 15 ist entweder 15.0 oder 15.1 oder 15.2 - alles ist Leap 15

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 120528 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Also verstehe ich das richtig, innerhalb einer Hauptversion (42, 15 ect) gibt es nur minimale Änderungen mit aber halbwegs aktuellen Programmen? D.h. man könnte es dann so machen, dass man auf Aktualisierungen auf neuere Minorversionen einfach die Konsole verwendet (mittels zypper dup wenn ich mich nicht irre) und Aktualisierungen auf Hauptversionen über eine frische Neuinstallationen durchführt. Das wäre zumindest meine Überlegung, weil ich denke irgendwann wäre eine frische Neuinstallation schon empfehlenswert. (Oder kann man etwa für immer eine Upgradinstallation aus dem laufenden Betrieb mittels Konsol machen?)

    Für den Inhalt des Beitrages 120569 haftet ausdrücklich der jeweilige Autor: Susetime

  • was du beschreibst ist ein gängiger Weg.
    Und hin und wieder mal eine 'frische Installation' ist nie verkehrt. Dann kann man einige selbst verbocke Altlasten auskehren.
    Es übt auch.


    Aber selbst der Wechsel zu einer neuen Hauptversion ist meist per ohne Probleme. Man sollte nur keine Versionen überspringen.

    There's no place like 127.0.0.1

    Einmal editiert, zuletzt von wurzel99 ()

    Für den Inhalt des Beitrages 120570 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Anmerkung: zypper dup ist die Kurzform von zypper dist-upgrade, DistributionsUPgrade DISTributionUPGRADE.


    Das ist der einfachste Weg ein System von z.B. 42.1 auf 42.2 zu bringen. Man muss nur vorher die Repoeinträge auf die neue Version umstellen.
    Das erledigt mit einem Schlag der Befehl sed -ir 's/42\.1/42.2/g' /etc/zypp/repos.d/*.
    Danach ein zypper clean -a && zypper dup && move kneipe
    Man sollte aber die Repos schon sorgfältiger umstellen. Bei den meisten Loosern haben sich ja irre viel sinnlose Repos eingebürgert. Bei vielen davon ist dann nicht klar, ob es die in der neuen Version überhaupt gibt.


    Aber im Wesentlichen genügen diese zwei Befehle um eine Installation in einem Rutsch von Version X auf Version Y zu bringen.


    Das funktioniert oft sogar über mehrere Versionen hinweg.
    Es sei denn, es hätte sich an zypper selbst etwas grundlegend geändert, was bisweilen vorkommt. Lieber hier erst nachfragen, ob ein zypper dup Aussicht auf Erfolg hat.

  • Du hast es doch zitiert und es ist - eigentlich - völlig klar.
    Prinzipiell wird also Leap 15 für 35 Monate unterstützt. Das findet statt in Form der 15.0/15.1/15.2 (oder 15.1/15.2/15.3), die ihrerseits jeweils für ca 18 Monate unterstützt werden.
    3x 18 Monat ergeben 35 weil sich die 18 jeweils deutlich überlappen.


    Ich habe mein Missverständnis endlich aufgedeckt: Ich habe zwischen Haupt- und Unterversionen unterschieden, was aber auch leicht passieren kann, wenn man sich das SUSE-Zitat anschaut:


    Zitat von SUSE

    Für jede Hauptversion (42, 15, usw.) ist ein Unterstützungszeitraum von mindestens 36 Monaten angedacht, bis die nächste Hauptversion verfügbar ist.
    Unterversionen (42.1, 42.2, usw.) werden ungefähr jährlich
    veröffentlicht. Nutzer sollten innerhalb von 6 Monaten nach der
    Veröffentlichung einer Unterversion auf diese aktualisiert haben, was zu
    einem Unterstützungszeitraum von 18 Monaten führt.

    Die missverstandene Deutung würde ja durchaus einen Sinn ergeben. Im Sinne von SUSE verstanden, ist es schlicht die Summe der Unterstützungszeiträume der Unterversionen, die den Unterstützungszeitraum der Hauptversion ergibt.
    Check :thumbup:




    Für die Zukunft hört sich das als Strategie gut an:

    Ich installieren mir immer die neueste Version auf eine 2 Festplatte. Von dort aus verlinke ich die wichtigen Datenverzeichnisse aus dem alten home-Verzeichnis (Bilder/dokumente/Downloads/videos ... ).Ich stelle im Bios diese HD als primäre Boot-HD ein.


    Wenn irgendwas nicht klappt habe ich immer die alte Version als fallback.
    Wenn dann die nächste Version kommt landet die wieder auf der 1. Platte.


    Läuft seit Jahren völlig reibungsfrei.


    Wie verlinkt man dann von dem neuen System auf die Dokumente im home-Verzeichnis?


    Dann zum Upgraden:
    Hier steht ja eine gute Anleitung von OpenSuse


    Darin wir empfohlen Zypper zu nehmen und nicht YAST (was ich schade finde). Und es scheint nur von der letzten Version aus zu gehen:


    Der unterstützte Startpunkt ist die letzte openSUSE-Version mit allen Aktualisierungen.


    Es könnte also über mehrere Versionen hinweg funktionieren- wie sieht das zwischen Hauptversionen aus?
    Konkret bei mir 42.2 --> 15.x


    A propos 15: ist ja gerade raus. Jemand hatte einen Fehler nach Installation: "Die Bildschirmsperre ist gestört und die Sitzung kann leider nicht freigegeben werden. Zum Freigeben [...] auf Konsole den Befehl loginctl unlock-session 2 [...] ausführen. [...]"


    Was kann das sein? Und: wann kommt die Folgeversion 15.x raus?




    Danke schonmal im Voraus!

    Für den Inhalt des Beitrages 121085 haftet ausdrücklich der jeweilige Autor: Suse-Paul