2. Bisherige Release-Zeitpläne

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.