Release-Zeitpläne von Linux-Distributionen

Einer der Aspekte der Linux-Arbeit im Vergleich zur Windows-Arbeit ist die Vielfalt und die Herausforderung unterschiedlicher Release-Zeitpläne. In der Windows-Welt ist dies recht einfach: Es gibt ein Produkt, und es erscheint, wenn es erscheint, was ungefähr alle zwei Jahre der Fall ist. Jeder, der mit Windows arbeitet, ist sich der bevorstehenden Releases sehr bewusst – wann sie erscheinen, wann sie in die Release-Candidate-Phase gehen, wann ihr Lebensende erreicht ist und so weiter. Es ist sehr klar und sehr einfach.

In der Linux-Welt ist dies ganz anders. Der größte Unterschied besteht natürlich darin, dass Windows ein Produkt ist, eine Sache, die von einem einzigen Hersteller kommt. Bei Linux sprechen wir von einer “Familie” verwandter Produkte von vielen Herstellern, einige davon mit mehreren Produkten. Dies kommt zusätzlich zum Release-Zeitplan des Kernels hinzu, der von Linux selbst stammt – um den wir uns hier nicht kümmern werden.

Jede Distribution ist einzigartig und trifft ihre eigenen Release-Entscheidungen. Tatsächlich ist der Release-Zeitplan oft ein Schlüsselfaktor dessen, was eine Distribution von einer anderen unterscheidet. Beispielsweise bieten alle drei führenden Enterprise-Linux-Hersteller zwei verschiedene Produkte an, und in allen drei Fällen erfolgt die Differenzierung in erster Linie über den Release-Zeitplan! Das Konzept des Release-Zeitplans ist in diesem Markt also gewiss ein wichtiges.

Es gibt drei grundlegende Release-“Stile”, die wir über alle Betriebssysteme hinweg vorfinden, nicht nur bei Linux-Distributionen: Long-Term-Release, Short-Term-Release und Rolling-Release. Jeder Release-Stil dient einem anderen Zweck, doch alle folgen im Allgemeinen einem ähnlichen Regelwerk.

Die Idee eines Release ist, dass sich die Pakete innerhalb eines Release außerhalb von Sicherheits- und Stabilitäts-Patches nicht ändern. Dies setzt natürlich das Verhalten der Enterprise-Hersteller voraus, wie es heute existiert; jede beliebige Distribution kann sich dafür entscheiden, etablierten Normen zu folgen oder nicht. Es gibt keine inhärenten Gesetze des Universums, die dieses Verhalten so machen, wie es ist; aber es ist eine starke Konvention, und das Konzept eines Release basiert auf dieser Konvention.

Long-Term-Release

Dieses Release-Modell ist im allgemeinen Bereich der Enterprise-Betriebssysteme am häufigsten und wird außerhalb von Linux von Systemen wie FreeBSD, Solaris, AIX, Mac OSX und Windows verfolgt. Long-Term-Releases, oft als LTS bezeichnet, sind auf langsame Systemänderungsraten ausgelegt und bieten Jahre, manchmal viele Jahre, zwischen großen Systemreleases, wodurch IT-Teams Migrationen viel länger vermeiden können und Softwareherstellern Ziele geboten werden, die über einen langen Zeitraum stabil sind.

In der Enterprise-Linux-Welt bieten alle Hersteller mindestens ein Long-Term-Release-Produkt an. Diese sind die am häufigsten bereitgestellten.

Von Red Hat sind die Produkte RHEL und CentOS Long-Term-Release mit äußerst langen Release-Zyklen – nicht nach einem festen Zeitplan, aber derzeit mit einem Release alle drei bis vier Jahre.

Suse hat zwei LTS-Produkte: Suse Linux Enterprise Server und openSuse Leap. SLES hält einen Release-Zeitplan ein, der derzeit zwischen drei und fünf Jahren liegt, und openSuse Leap orientiert sich relativ eng an den SLES-Releases.

Ubuntus LTS-Release trägt praktischerweise den Namen LTS und erscheint alle zwei Jahre in den geraden Jahren, im April, wie ein Uhrwerk. Ubuntu hat derzeit den kürzesten Release-Zyklus aller LTS-Produkte in dieser Kategorie.

Alle Long-Term-Releases haben Minor-Releases, die zwischen den Major-Releases erscheinen und kleine Änderungen oder Anpassungen an den Betriebssystemen mit sich bringen, die größer sind, als es angemessen wäre, sie mit einem Patch auszuliefern, aber nicht groß genug, um ein Release eines neuen Betriebssystems zu rechtfertigen. Die Idee dieser Minor-Releases ist, dass sie klein genug sind, um nicht “breaking” zu sein, sodass Software, die auf das Major-Release abzielt, während des gesamten Major-Release-Zyklus funktionsfähig bleibt. Major-Releases gelten als “breaking” mit großen Änderungen wie bedeutenden neuen Kernel-Funktionen, Änderungen bei der Paketauswahl, neuen Compiler-Funktionen, anderen Bibliotheken und so weiter.

Short-Term- oder Rapid-Release

Long-Term-Release-Zeitpläne schaffen offensichtlich Probleme für diejenigen, die nach moderneren Paketen und Funktionen suchen. Um dem zu begegnen, bieten alle Enterprise-Linux-Hersteller ein Short-Term-Release-Produkt an.

Red Hat stellt die Fedora-Distribution bereit, die ungefähr alle sechs Monate erscheint, jedoch mit einem flexiblen Zeitplan. Fedora ist nicht ganz eine separate Distribution gegenüber RHEL und CentOS, sondern stattdessen wird hin und wieder ein Fedora-Release ausgewählt, um die “Basis” für ein zukünftiges RHEL- und CentOS-Release zu bilden. Die Grundlage ist nicht direkt, und manche Pakete aus späteren Fedora-Releases werden mitunter hinzugefügt, manche Änderungen werden vorgenommen, aber die Grundlagen entsprechen eng einem Fedora-Release. Das Fedora-Release wird eingefroren und durchläuft umfangreiche Tests, bevor es zu einem Long-Term-RHEL-Release wird.

Die Suse-Familie verwendet kein Short-Term-Release-Produkt und ist darin einzigartig.

Ubuntu verfolgt eine etwas andere Strategie als Red Hat. Ubuntu veröffentlicht alle sechs Monate ein Produkt, nach einem sehr festen Zeitplan. Jedes vierte Release wird als Long-Term-Release vorgesehen, die anderen drei sind Short-Term-Releases. Dies sorgt für ein weitaus einfacheres und unkomplizierteres System als die Arbeitsweise von Red Hat, bei der sich Short-Term-Release-Nutzer und Long-Term-Release-Nutzer alle zwei Jahre für sechs Monate überschneiden.

Rolling-Release

Der schnellere Release-Zeitplan-Typ ist der des Rolling-Release, das im Grunde kontinuierlich erfolgt. Diese Release-Strategie ist ungewöhnlich, wird aber in jüngerer Zeit zunehmend ernster genommen. Nur Suse stellt mit der openSuse-Tumbleweed-Distribution heute ein Enterprise-Rolling-Release-System bereit. Updates können so häufig wie alle paar Tage erfolgen.

Anders als andere Release-Zeitpläne, die große Gruppen von Paketen nehmen und sie als ein einziges Release “einfrieren”, hat das Rolling-Release Updates für einzelne Pakete, die erscheinen, sobald sie bereit sind. Updates sind also klein, aber konstant. Dies ermöglicht eine vereinfachte Anpassung, indem Änderungen auf einer Mikroebene gehalten werden, macht es aber sehr schwierig, ein einzelnes, vorhersehbares Ziel zu schaffen.

Wer nach den aktuellsten Paketen und modernsten Funktionen sucht, wird Rolling-Releases als den besten Weg empfinden, alles so aktuell wie möglich zu halten.

---

Ein wichtiges Verständnis von Release-Zeitplänen ist, dass diese weder direkt mit der Dauer des für ein Release gewährten Supports verknüpft sind noch den Umfang der Tests angeben, der in jedes Release einfließt.

Jeder Release-Stil spielt eine wichtige Rolle im System-Ökosystem, und durch das Vorhandensein verschiedener Release-Stile verfügt die Enterprise-Linux-Welt über größere Vielfalt und Flexibilität, um ein breiteres Spektrum an Bedürfnissen zu bedienen, als es andernfalls machbar wäre.

Derzeit sind Long-Term-Releases die prominentesten und beliebtesten in der Systemadministration, doch dieser Trend wird sich wahrscheinlich nicht fortsetzen. Die allgemeine Stabilität im gesamten Enterprise-Linux-Bereich hat zugenommen, und der Bedarf an Aktualität ist so oft ein kritischeres Anliegen, dass schnellere Distributionen zunehmend gefragt sind.