Kleine SeaMonkey-Versionslehre

Trunk, Branch & Co.

von Stephan Hohe

Grundsätzlich ist da mal der Trunk. Da basteln alle dran rum und bauen neue Features ein und fixen Bugs und so weiter. Davon werden die Nightlies erzeugt, um die ganzen Änderungen zu testen (und eigentlich nur dazu!). Da aber der Trunk somit laufend "im Fluss" ist und laufend Änderungen gemacht werden, entstehen dabei auch immer wieder unvorhergesehene Probleme. Um ab und zu mal wirklich stabile Versionen zu bekommen, bei denen sicher ist, dass nicht irgendeine nagelneue Änderung gerade wieder irgendwas durcheinandergehaut hat, werden ab und zu die Milestones veröffentlicht.

Dazu gibt es jedes Vierteljahr ein sog. Feature-Freeze, ab dem keine neuen Features mehr eingebaut werden und nur noch schwerwiegende Probleme der aktuellen Trunk-Version gefixt werden. Hat man dann ein Produkt das zumindest in allen Grundfunktionen funktioniert, wird ein neuer Branch abgetrennt. Danach hat man den Sourcecode sozusagen zweimal, einmal den normalen Trunk und einmal den Branch. Im Trunk wird daraufhin munter weiter gebastelt und wieder normal verfahren, der Branch wird noch weiter getestet und dort werden nur noch Fehler beseitigt. Nebenbei werden sowohl im Trunk als auch im Branch immer Nightlies zum Testen erzeugt. Und wenn schließlich im Branch keine schwerwiegenden Fehler mehr entdeckt werden und bei den mittelschweren nicht abzusehen ist, dass die in naher Zukunft bereinigt werden, dann wird die Branch-Version veröffentlicht und Milestone genannt. Die Milestones sind daher immer besonders fehlerfrei, da einige Zeit vorher nur Fehler ausgebessert und keine riskanten Neuerungen mehr eingeführt werden. Im Trunk dagegen kann parallel zum reinen Fehlerverbessern im Branch schon wieder normal weitergearbeitet werden.

Vergleicht man einen aktuellen Milestone mit einem aktuellen Nightly aus dem Trunk, hat also im allgemeinen das Nightly mehr Features, aber auch mehr Bugs. (Jedenfalls in der Theorie. pi)

Wieso werden Bugs im Branch erst später ausgebessert?

Wenn ein Bugfix vorhanden ist, wird dieser zuerst im Trunk eingecheckt. Dann wird erst ein wenig abgewartet, ob das Problem wirklich gelöst ist — also ob sich der Patch im Trunk bewährt —, und wenn das gesichert ist und auch keine neuen Probleme durch den Patch aufgetaucht sind, wird er wahrscheinlich auch im Branch hinzugefügt. Allerdings kann das schon ein wenig dauern, da natürlich alle besonders sicher gehen wollen, keine neuen Fehler mehr einzubauen.

Versionsnummern

von pi

Gegeben seien zwei unmittelbar aufeinanderfolgende Versionsnummern n und m, vgl Roadmap.

In dem Moment, zu dem der Branch n abgezweigt wird (der Zeitpunkt heisst auch branch bgzl. n), wird im Trunk mit der Arbeit für Version m begonnen (dieser Zeitpunkt heisst start für m). Gelegentlich liegen diese Zeitpunkte getrennt, was eigentlich nicht so sein sollte. Der Trunk befindet sich jetzt also auf dem Weg zu m, man könnte hier von pre-m sprechen, tatsächlich wird diese Versionsserie jedoch mit n+ bezeichnet.

Der nächste Schritt ist dann der Zeitpunkt freeze (für m). In der hier beginnenden Phase gelten strengere Regeln für die Einarbeitung von Änderungen, sie ist gewöhnlich nur sehr kurz.

Es folgt der Zeitpunkt branch, ab dem Version m vorbereitet wird. Wie oben beginnt im Trunk die Arbeit an m+. Im Branch wird die Release m vorbereitet.


Valid CSS!Valid HTML 4.01!
© Boris 'pi' Piwinger, September 6, 2008