Lange oder kurze Release-Zyklen? Nachteile kurzer Versionsabstände [2/2]

Im gestrigen Artikel ging ich auf die Vorteile kurzer Zeitabstände zwischen zwei Software-Versionen ein. Heute will ich die Gegenseite etwas beleuchten und Vorteile langer Release-Zyklen ansprechen.

Je nach Art der Software

Prinzipiell bin ich der Meinung, dass hauptsächlich die Art der Software für die Wahl eines geeigneten Release-Zyklus entscheidend ist. Ein Betriebssystem muss nicht so oft aktualisiert werden, wie ein Anwendungsprogramm. Ein Betriebssystem soll in erster Linie nämlich funktionieren und die stabile Grundlage für darauf laufende Programme darstellen. Allerdings muss man hierbei wieder zwischen den einzelnen Betriebssystemen differenzieren. Während ein Windows über Jahre laufen sollte und Programme unabhängig davon laufend aktualisiert werden, sieht es bei den Linux-Distributionen anders aus.

Kompromiss zwischen Stabilität und Aktualität

Ein großer Teil der Linux-Distributionen unterscheidet nicht zwischen Betriebssystem und Anwendungsprogramm – zumindest nicht in der Art, wie diese aktualisiert werden. Ubuntu zum Beispiel erscheint alle sechs Monate. Die Software, die mittels Paketmanager installiert wird, wird allerdings ebenfalls nur dann auf den neuesten Stand gebracht, wenn man auf die neueste Version von Ubuntu aktualisiert. Benutzt man weiterhin die aktuell laufende Version, stehen lediglich Sicherheitsaktualisierungen und Fehlerbehebungen zur Verfügung. Wer neue Software will, benötigt theoretisch also auch ein aktuelles Betriebssystem. Klar kann man von Hand auch aktuelle Software auf etwas älteren Versionen zum Laufen bringen. Standardmäßig ist es aber so, dass sich sowohl Betriebssystem als auch darauf aufsetzende Software nur in gewissen Abständen aktualisiert.

Während ein Windows-Betriebssystem also durchaus mal älter als ein paar Jahre sein kann, ist dies unter Linux für normale Benutzer nicht wirklich komfortabel. Der Release-Zyklus der meisten Linux-Distributionen ist ein Kompromiss zwischen Stabilität und Aktualität. Beispiele dafür sind:

• Debian stable: Ca. alle 2 Jahre eine neue Version. Sehr stabil, aber auch sehr veraltet.
• Debian unstable (sid): Running release, Pakete werden fortlaufend aktualisiert. Nicht stabil, sehr aktuell.
• Ubuntu, Fedora: Alle 6 Monate ein neues Release (Kompromiss zwischen Stabilität und Aktualität)
• openSUSE: Alle 9 Monate ein neues Release (Kompromiss zwischen Stabilität und Aktualität)

Kommerzielle Programme

Bei kommerziellen Programmen finde ich zu kurze Release-Zyklen meist unvorteilhaft. Zum einen fällt das Argument für kurze Zyklen weg, dass die Programmierer bei Laune gehalten werden müssen, da diese nicht nur wegen Lust und Laune arbeiten, sondern eben (auch) Geld mit der Arbeit verdienen. Auf der anderen Seite wird eine neue Version eines kommerziellen Programmes meist aufwändig beworben. Diese Werbung kostet viel Geld und zahlt sich wahrscheinlich nur dann aus, wenn man auch wirklich große, neue Funktionen zum Bewerben hat.

So ähnlich gestaltet es sich bei Spielen. Auch dabei sollte es neue Versionen in eher großen Abständen geben. Vor allem bei Online Multiplayer-Spielen ist es sinnvoll, eine Version lange aktuell zu halten. Ansonsten kommt es zur Fragmentierung verschiedener Versionen. Da Multiplayer-Spiele meistens nur zwischen Spielern gleicher Version funktioniert, ist eine hohe Anzahl an Versionen nicht zu begrüßen.

Fazit

Man kann also von Haus aus nicht sagen, ob kürzere oder längere Versions-Zyklen zu bevorzugen sind. Prinzipiell bin ich persönlich ein Fan von kurzen Zyklen, da ich meist relativ ungeduldig gegenüber Neuerungen bin und vor allem bei OpenSource-Projekten Veröffentlichungen eine Art Lebenszeichen sind. Allerdings gibt es doch einige Fälle, wo eher große Versionssprünge zu bevorzugen sind. Geradeim kommerziellen Bereich scheint dies die bessere Lösung zu sein.