Copyright © 2005 The FreeBSD Documentation Project
$FreeBSD: head/de_DE.ISO8859-1/articles/version-guide/article.sgml
39544 2012-09-14 17:47:48Z gabor $
Damit Sie sich für die für Sie am Besten geeignete FreeBSD-Version entscheiden können, müssen Sie einige Konzepte unseres Entwicklungs- und Release Engineering (RE)-Prozesses verstehen.
FreeBSD wird von einer großen Gruppe von fast ausschließlich freiwilligen Mitarbeitern entwickelt. Der Quellcode des Kernels und der Systembibliotheken wird durch ein Versionskontrollsystem verwaltet und kann jederzeit heruntergeladen werden. Zusätzlich werden in regelmäßigen Abständen binäre Installationspakete erstellt. Einige dieser Binärversionen durchlaufen einen intensiveren Testprozess und werden danach als Release veröffentlicht.
Releases werden durch eine Hauptversionsnummer sowie eine Unterversionsnummer gekennzeichnet.
Das Ziel eines Haupt-Releases ist es, neue Funktionen einzuführen. Dafür kann es auch nötig sein, die Kompatibilität mit Vorgängerversionen zugunsten der Weiterentwicklung von FreeBSD aufzugeben. Andererseits werden manchmal Funktionen aus dem System entfernt, die nicht länger benötigt werden.
Eine Unterversion wird veröffentlicht, um Probleme zu beheben sowie die Leistung und Stabilität des Systems zu verbessern. Dabei hat aber die Erhaltung der Kompatibilität zwischen den einzelnen Unterversionen Priorität. Ist die Einhaltung dieser Vorgaben gewährleistet, werden gelegentlich auch in Unterversionen neue Funktionen eingeführt.
Beachten Sie aber, dass eine “Release-Version” lediglich den Stand des Quellcodes zu einem bestimmten Zeitpunkt darstellt, dem ein Name (ein sogenanntes Tag) zugewiesen wurde. So hat das Release Engineering Team dem Release 5.4 das Tag RELENG_5_4_0_RELEASE zugewiesen. Der aktuelle Entwicklungsstand wird hingegen durch das Tag HEAD gekennzeichnet.
Zeitgleich mit der Veröffentlichung einer Release-Version wird ein Zweig (branch) erzeugt (in unserem Beispiel RELENG_5_4). Der Quellcode von RELENG_5_4_0_RELEASE bleibt danach unverändert, während sich Dateien des Zweiges RELENG_5_4 sehr wohl verändern können, wenn Änderungen wie Behebungen von Sicherheitslücken oder anderen Problemen von HEAD übernommen werden.
Während der Lebenszeit einer Hauptversion wird ein weiteres Tag vergeben, beispielsweise RELENG_5. In diesen Zweig können zusätzlich zu den eben genannten Aktualisierungen auch weitere Neuerungen von HEAD übernommen werden, um so den Übergang zur nächsten Unterversion vorzubereiten.
Während der Lebenszeit einer Hauptversion kann auch ein STABLE-Zweig erzeugt werden. Dadurch wird signalisiert, dass das FreeBSD-Projekt der Ansicht ist, dass dieser Zweig nun so stabil ist, dass er für die meisten Anwender geeignet ist. Ein Zweig, der vor seiner Eignung für den allgemeinen Einsatz noch weiter getestet werden muss, wird hingegen als CURRENT bezeichnet.
Anmerkung: Das FreeBSD-Projekt übernimmt keine Garantie dafür, dass die vertriebene Software für alle Einsatzzwecke stabil genug ist. Diese Entscheidung kann nur der jeweilige Anwender selbst treffen. Bedenken Sie auch, dass das FreeBSD-Projekt sich fast ausschließlich aus Freiwilligen zusammensetzt. Daher kann auch nicht garantiert werden, dass die Software für Ihre Anforderungen geeignet ist.
Neben dem Betriebssystem selbst unterstützt FreeBSD auch Tausende Anwendungen, die unabhängig vom Projekt selbst von Dritten entwickelt werden. Dazu gehören Window-Systeme, Internetbrowser, E-Mail-Programme, Office-Programme und viele andere mehr. Das FreeBSD-Projekt stellt dazu in der Regel nur das als Ports-Sammlung bezeichnete Gerüst bereit, damit diese Programme unter FreeBSD installiert werden können. Ein Programm, dessen Lizenz die Installation aus dem Quellcode erlaubt, wird als Port bezeichnet, ein Programm, das aus einer vorkompilierten Binärdatei installiert wird, hingegen als Paket (package).
Während der Entwicklung von FreeBSD 5.X traten Probleme auf, deren Tragweite erst im Nachhinein vollkommen klar wurde. Die Entwicklungsziele für die 5.X-Reihe waren äußerst ambitioniert und sahen unter anderem vor:
Die Unterstützung von Mehrprozessor-Systemen (Symmetric MultiProcessing (SMP)).
Die Erhöhung der Leistungsfähigkeit durch die Entwicklung einer neuen Strategie für das Ressourcenmanagement innerhalb des Kernels.
Die zusätzliche Unterstützung von verschiedenen Prozessor-Architekturen.
Die Einführung eines neuen Modells für die Handhabung von Threads.
Die Entwicklung eines neuen Schedulers.
Die Unterstützung neuer Technologien wie Power Management (insbesondere auf Notebooks).
All dem übergeordnet war die Festlegung, die 5.X-Serie erst dann für STABLE zu erklären, wenn all diese Aufgaben erledigt waren.
Dies führte dazu, dass zwischen dem Entstehen des STABLE-Zweiges von 4.X beziehungsweise 5.X mehrere Jahre vergingen. Dieser Umstand hatte mehrere unerwünschte Auswirkungen:
Die große Anzahl der gleichzeitig zu implementierenden Neuerungen machte es sehr schwierig, einen Teil davon zu isolieren und in den STABLE-Zweig einzubringen.
Anwender, die bestimmte Neuerungen unbedingt benötigten (etwa die Unterstützung neuester Hardware), entschieden sich vielfach dafür, beispielsweise FreeBSD 5.2.1 zu installieren, obwohl es sich dabei um ein CURRENT-Release handelte, das nur für Entwickler und nicht für den allgemeinen Einsatz vorgesehen war.
Um Änderungen aus diesen Versionen wieder in den aktuellen Entwicklungszweig einzubringen, waren die Entwickler gezwungen, diese Eigenschaften auf FreeBSD-Versionen zu unterstützen, die sie nicht als primäre Entwicklungsplattform nutzten.
Die zeitliche Verzögerung bis zum Erscheinen von FreeBSD 5.3, dem ersten STABLE-Release, führte zu umfangreichen Änderungen, was die Aktualisierung auf die neue Version äußerst kompliziert machte.
Um es auf den Punkt zu bringen: Niemand war mit dieser Entwicklung zufrieden.
Aus dieser Problematik wurden daher folgende Rückschlüsse gezogen:
Neue Hauptversionen werden künftig nicht mehr so umfangreiche Änderungen aufweisen. Dafür werden solche Versionen häfiger veröffentlicht werden.
Soweit möglich, sollen Funktionserweiterungen künftig voneinander isoliert entwickelt werden. Dies setzt voraus, dass Teile der Entwicklungsarbeit außerhalb des Hauptquellcodebaumes erfolgen. Änderungen werden erst dann in den Hauptentwicklungszweig eingebracht werden, wenn sichergestellt ist, dass diese die Stabilität anderer Entwicklungsprojekte nicht beeinträchtigen.
Hauptversionen werden sich künftig an einem Zeitplan orientieren und nicht mehr an den zu implementierenden Änderungen. Wenn bestimmte Eigenschaften zum geplanten Veröffentlichungszeitpunkt nicht fertig werden, werden sie vorerst deaktiviert und erst in der nächsten Hauptversion aktiviert.
Durch die häufigere Veröffentlichung von weniger umfangreichen Änderungen erhofft man sich außerdem, dass die Einbringung von neuen Eigenschaften aus HEAD in die neue STABLE-Version erleichtert wird. Dadurch können solche Eigenschaften in mehreren Hauptversionen unterstützt werden. Da es sich dabei in der Regel um isolierte Änderungen handeln wird, verringert sich auch die Wahrscheinlichkeit, dass mit diesen Änderungen neue Probleme eingeführt werden.
Durch die Fokussierung auf einen Zeitplan statt auf geplante Änderungen wird es für Anwender, Entwickler von externen Programmen sowie FreeBSD-Entwickler einfacher werden, eigene Planungen zu erstellen.
So sehen die derzeitigen Planungen des FreeBSD-Projekts für zukünftige Versionen aus:
Alle 18 Monate soll eine neue Hauptversion veröffentlicht werden.
Eine Unterversion soll hingegen alle 4 Monate veröffentlicht werden.
Für das jeweils aktuellste Unterversion-Release jeder Hauptversion sollen vorkompilierte Pakete angeboten werden.
Sicherheitslücken und andere kritische Probleme sollen für die aktuellsten Unterversionen jeder Hauptversion angeboten werden (in sogenannten security branches).
Aufgrund der vielen verschiedenen installierbaren Versionen, ist es allerdings nicht möglich, jede Version zeitlich unbegrenzt zu unterstützen. Dies liegt zum Teil an nur begrenzt verfügbaren Rechnerkapazitäten, vor allem aber an der ebenfalls nur begrenzt verfügbaren Leistung der freiwilligen Mitarbeiter des FreeBSD-Projekts.
Interessierte Leser sollten sich auch folgende Seiten ansehen:
The Release Engineering Schedule
The Security Branch Schedule
Beide Dokumente gehen näher auf die verschiedenen Entwicklungszweige sowie den Zeitrahmen ein, für den die einzelnen Zweige unterstützt werden.
Die wichtigsten Fragen, die Sie sich vor der Entscheidung für die zu installierende Version stellen sollten, sind:
Wie stabil muss Ihre Installation sein?
Wie viel Arbeit wollen Sie in den Aktualisierungsprozess investieren?
Wie lange wollen Sie mit einer bestimmten Version arbeiten, bevor Sie auf eine neuere Version wechseln?
Wie sicherheitskritisch ist Ihre Installation?
Wollen Sie Ihr System aus dem Quellcode installieren oder bevorzugen Sie eine Binärinstallation?
Sind Sie bereit, sich am FreeBSD-Entwicklungsprozess zu beteiligen?
Es folgen nun einige grobe Richtlinien, die Ihnen bei Ihrer Entscheidung helfen sollen:
Wenn Sie an der derzeit stabilsten Version interessiert sind und möglichst wenig Ressourcen in die Aktualisierung Ihres Systems investieren wollen, sollten Sie das aktuellste STABLE-Unterversions-Release installieren und bei dieser Version verbleiben. Dabei bleibt es Ihnen überlassen, ob Sie Änderungen dieses Zweiges übernehmen wollen oder nicht.
Wenn es Ihnen auf auf eine sofortige Verfügbarkeit ankommt, Sie die neuesten Fähigkeiten oder den bestmöglichen Sicherheitslevel benötigen und dazu bereit sind, Zeit in die Aktualisierung Ihres Systems zu investieren, können Sie dem aktuellen STABLE-Zweig folgen.
Wenn Sie Ihr System nicht sofort benötigen und bereit sind, sich durch einige Probleme zu arbeiten, können Sie uns dabei helfen, eine neue bevorstehende Hauptversion zu testen, um für diesen Zweig mittel- bis langfristig die bestmögliche Stabilität zu erreichen.
Nur wenn Sie bereit sind, das System aus dem Quellcode zu installieren, Zeit haben, Probleme im Basissystem zu suchen und zu beheben sowie entsprechende Problemberichte zu erstellen und zusätzlich die entsprechende Mailingliste verfolgen können, sollten sich dafür entscheiden, HEAD zu folgen.
Wir hoffen, dass dieser Artikel Ihr Verständnis des FreeBSD-Entwicklungsmodells verbessern und Ihnen Ihnen dabei helfen konnte, sich für die FreeBSD-Version zu entscheiden, die Ihren Anforderungen am Besten entspricht.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.