RELEASE, STABLE und CURRENT bei FreeBSD

Betrifft OS:
FreeBSD

Was bedeutet RELEASE, STABLE und CURRENT?

FreeBSD gibt es in verschiendenen Varianten.

Für den eiligen Leser siehe Zusammenfassung unten.

FreeBSD hat ein auf Zweigen aufbauendes System an Versionen. Jede Version führt zu einer Gabelung („Fork“) eines Zweiges. Der Hauptzweig ist „CURRENT“ aka „HEAD“ und führt zu der nächsten Hauptversion. Im Moment (Januar 2013) ist es z.B. „10-CURRENT“ und wird irgendwann 2013 oder 2014 zu FreeBSD 10.0 werden. CURRENT ist dabei eine höchst instabile Entwicklerversion und sollte von Endnutzern nicht genutzt werden, da man sich daran die Finger schön zerschneiden kann.

Kurz vor dem Erscheinen einer Hauptversion verzweigt sich CURRENT. Das geschah z.B. im September 2011. Aus 9-CURRENT wurde 10-CURRENT und 9-STABLE. Das Wort von „STABLE“ kommt nicht wie ein vielen Linuxen von „Stabiles System“, stattdessen von „Stabile ABI“. Die ABI bricht innerhalb eines Zweiges nicht, d.h. alle für 9.x geschriebenen Programme und Kernelmodule können auf allen 9.x Systemen mit gleicher oder höherer Unterversionnummer genutzt werden. 9-STABLE ist also das, was zum nächsten 9.x Unterrelease führt. Stelle dir Unterreleases wie Service Packs unter Windows vor, kleinere Verbesserungen, Bugfixes, Neuerungen, aber nichts weltbewegendes.

Im Oktober 2011 spaltete sich dann das neue 9-STABLE gleich wieder in 9.0-STABLE und 9.0-RELEASE. 9.-RELEASE wurde zu dem RELEASE von 9.0. Es besteht aus mehreren Release Candidates, nämlich dem Release selbst und anschließenden Sicherheitspatches für dieses, z.B. 9.0 Release -p1.

9.0-STABLE führte zu 9.1-RELEASE im Dezember 2012.

Der Fluss von Features ist: Dinge werden in Projektbranches entwickelt und gehen dann in CURRENT ein. Nach einiger Zeit können sie in -STABLE zurückportiert werden, man nennt es einen „Merge from CURRENT“ oder kurz MFC. Dabei können logischerweise nur Dinge geMFCt werden, die die ABI nicht verändern.

FreeBSD hat innerhalb einer „Branch“ eine stabile ABI, das bedeutet man kann Programme von Version 6.0 ohne Probleme auch unter Version 6.3 nutzen. Eventuelle Probleme mit Abhängigkeiten hier mal unberücksichtigt.

Dieses Modell bedingt, dass es mehrere aktive Branches geben kann. Das sind derzeit (Januar 2013):

  • 7.4-STABLE (es wird allerdings kein 7.5-RELEASE mehr geben)
  • 8.3-STABLE (führt zu 8.4-RELEASE, wahrscheinlich nachdem 9.1 durch ist)
  • 9.1-STABLE (führt zu 9.2, ca. Mitte/Ende dieses Jahres)

Updates sind das ganz einfach:

-STABLE und -CURRENT bekommen Updates im Rahmen ihrer normalen Entwicklung. RELEASES werden nach dem Muster vergeben, das gerade Versionen (9.0, 9.2, 9.4, etc) 1 Jahr Sicherheitsupdates bekommen. Ungerade Versionen (9.1, 9.3, etc.) zwei Jahre. Das letzte RELEASE aus einem Zweig (z.B. 7.4) hat immer 2 Jahre. Eine Branch lebt damit ca. 5 bis 7 Jahre, was in etwa die Supportzeiträume sind, die auch die meisten Linuxe bieten.

Und um es nochmal deutlich zu sagen: Ports haben nichts damit zu tun!

FreeBSD unterstützt immer Upgrades, aber keine Downgrades. Wichtig ist nur, dass immer nur von der vorherigen Hauptversion unterstützt wird. Du kannst also ein FreeBSD 8.x auf 9.x aktualisieren, ein FreeBSD 7.x aber nicht. Da müsstest du erst 7.x → 8.x und danach 8.x → 9.x.

Bezeichnungen in den Repositories

Platzhalter für Versionsnummern:

  1. M: Major Version, zum Beispiel die 9 in FreeBSD 9
  2. m: Minor Version, zum Beispiel die 1 in FreeBSD 9.1
  3. p: Patchlevel, zum Beispiel die 0 in FreeBSD 9.1.0
Umgangssprachlich SVN CVS (veraltet) Funktion
CURRENT oder M-CURRENT head HEAD Bleeding Edge Entwicklungszweig, Nutzung auf eigene Gefahr, nicht für produktive Maschinen
M-STABLE stable/M RELENG_M Entwicklungszweig für das nächste Minor Release, kein Bruch des ABI
releng/M.m RELENG_M_n Entwicklungszweig für ein spezifisches Minor Release, keine neuen Features
M.m-RELEASE release/M.m.0 RELENG_M_m_0_RELEASE Ein offizielles FreeBSD Release, z.B. 9.1.0 wird als 9.1 bekannt gegeben
release/M.m.p RELENG_M_m_p_RELEASE Ein offizielles FreeBSD Release mit Security Patches

Zusammenfassung

RELEASE

RELEASE ist eine Gabelung von STABLE. Es werden nur RELEASEs unterstützt (supported).

STABLE

Die Bezeichnung STABLE kommt von „stabiler ABI (Binärschnittstelle)“ und nicht, wie oft fälschlich angenommen wird, von „stabilem System“.

CURRENT

STABLE und CURRENT sind Entwicklungsversionen. Diese sind definitiv nicht für den produktiven Einsatz gedacht und erhalten daher auch keine Unterstützung. STABLE läuft in der Regel schon sehr zuverlässig, aber es besteht hier immer die Möglichkeit, daß nach dem Einspielen aktuellerer Sourcen, das System nicht mehr benutzbar ist.

Worst Case Scenario

Diesen Fall gab es zuletzt am 25.10.2007. Dort wurde aus Versehen ein Commit auf 6.2-STABLE vorgenommen, mit welchem Inkompatibilitäten in die ABI gebracht wurden. Dies darf natürlich nicht sein und daher gab es damals einen „Backout“: Es wurde der Commit am 30.10.2007 rückgängig gemacht. Man dachte, daß Problem sei beseitigt. Alle Benutzer die innerhalb dieser 5 Tage Programme kompiliert hatten, mussten diese erneut kompilieren und alles war gut.

Was nicht bedacht wurde, war die Tinderbox, welche ständig die Ports durchkompiliert, um Fehler in den Ports und Packeten zu finden. Diese kopiert nun ihre Pakete regelmäßig in das „Latest“-Verzeichnis. Hintergrund ist, daß man die testweise erstellten Packete auch Online stellt, bevor man sie einfach löscht. Leider lief nun Tinderbox auf einem 6.2-STABLE aus dem fraglichen Zeitraum mit defekter ABI. Alle Benutzer, die „Latest“-Pakete installiert haben, haben somit die Programme und Libraries mit defekter ABI installiert.

Schlußfolgerung

Auf produktiven Systemen hat irgendwelcher, nicht unterstützter Kram, nichts zu suchen. Die „Latest“-Pakete sind eine reine Gefälligkeit. Sie werden nicht unterstützt und haben nicht den Anspruch zu funktionieren. Sie sind ein Abfallprodukt der Tinderbox. Wenn man diese Programme/Packete nutzt und sie vorher nicht einer Testumgebung ausprobiert, hat man das Nachsehen. Aus diesem Grund gibt es im „Latest“-Verzeichnis übrigens auch nur selten Metaports.

Quelle: Yamagis Forenbeitrag