Die meisten ausgereiften Projekte pflegen mehrere Versionszweige nebeneinander. Nachdem 1.0.0 erscheint, sollte diese Reihe mit micro Versionen (Fehlerbehebung) 1.0.1, 1.0.2, usw., so lange weiter geführt werden, bis das Projekt sich explizit entscheidet die Reihe zu beenden. Beachten Sie, dass die Veröffentlichung der 1.1.0 kein ausreichender Grund ist die 1.0.x Reihe zu beenden. Manche Nutzer aktualisieren zum Beispiel prinzipiell nicht auf die erste Version einer minor oder major Reihe—sie lassen andere die Fehler herausfinden, sagen wir bei der Version 1.1.0, warten sie bis 1.1.1. Das ist nicht zwangsläufig egoistisch (bedenken Sie, dass sie auch den Bugfixes und neuen Funktionen entsagen); sie haben sich nur entschieden, aus welchen Gründen auch immer, dass sie sehr vorsichtig bei Aktuelisierungen sind. Wenn das Projekt von einem ernsthaften Fehler in 1.0.3 erfährt, kurz vor der Veröffentlichung von 1.1.0, wäre es entsprechend hart, den Bugfix nur in 1.1.0 zu stecken, und alle Nutzer der alten 1.0.x Reihe zu sagen, dass Sie aktualisieren sollen. Warum nicht sowohl 1.1.0 als auch 1.0.4 veröffentlichen, damit alle glücklich sind?
Nachdem die 1.1.x Reihe gut läuft, können Sie für 1.0.x erklären, dass es am ende seines Lebenszykluses (en. end of life ) ist. Das sollte offiziell bekannt gegeben werden. Die Bekanntgabe kann einzeln gemacht werden, oder es kann als Teil der Ankündigung einer neuen 1.1.x Version geschehen; wie Sie es auch machen, die Nutzer müssen wissen, dass die alte Reihe ausläuft, damit sie entsprechende Entscheidungen im Bezug auf Aktuelisierungen machen können.
Manche Projekte legen einen Fenster fest, indem sie versprechen die vorhergehende Versionsreihe zu pflegen. Im Kontext von Open Source, bedeutet "pflege" (en. "support") die annahme von Bug Meldungen für diese Reihe, und neue Versionen zu veröffentlichen, wenn bedeutende Fehler gefunden werden. Andere Projekte geben keine definitive Zeitangabe, halten aber ein Auge auf eintreffende Bug Meldugen um einen Überblick zu behalten, wie viele Personen die alte Reihe noch verwenden. Wenn der Prozentsatz unter einem gewissen Anteil sinkt, erklären sie für die Reihe, dass es am ende seines Lebens ist und hören auf es zu pflegen.
Sorgen Sie bei jeder neuen Version dafür, dass ein target version (de. Zielversion) oder target milestone (de. Ziel-Meilenstein) in dem Bug Tracker zur verfügung steht, damit Personen die Bugs finden, ihre Meldungen unter der richtig Version einordnen können. Vergessen Sie nicht auch einen Ziel namens "development" (de. Entwicklung) oder "latest" (de. aktuelle) für den neusten Quellcode zu haben, da manche —nicht nur die aktiven Entwickler— oft den offiziellen Versionen voraus bleiben werden.
Die meisten Details über die Handhabung von Sicherheitslücken wurden in „Bekanntgabe von Sicherheitslücken“ im Kapitel Kapitel 6, Kommunikation behandelt, es gibt aber ein paar besondere Details, die es für Sicherheits-Versionen zu besprechen gibt.
Eine Sicherheits-Version ist eine Version die nur gemacht wird, um eine Sicherheitslücke zu schließen. Der Code welcher den Bug behebt, kann nicht veröffentlicht werden, bis die neue Version zur verfügung steht, was nicht nur bedeutet, dass die Fixes nicht zu der Repository committed werden können, bis zum Tag der Veröffentlichung, sondern dass die Version nicht öffentlich getested weden kann, bis es freigegeben wird. Die Entwickler können den Fix offensichtlich unter sich untersuchen, und die neue Version im private testen, aber breites testen unter realen Bedingungen ist nicht möglich.
Aufgrund von diesem Mangel an Tests, sollte eine Sicherheits Version immer aus einer bestehenden Version bestehen mit den Fixes für die Sicherheitslücke, ohne irgend welche anderen Änderungen. Denn je mehr Änderungen Sie in einer Version veröffentlichen, desto wahrscheinlicher ist es, dass einer von ihnen einen neuen Fehler verursachen wird, vieleicht sogar eine neue Sicherheitslücke! Konservativ zu sein, ist auch freundlich für Administratoren welche den Sicherheits Fix möglicherweise einspielen müssen, dessen Richtlinien im Bezug auf aktuelisierungen es aber bevorzugen, dass sie zur gleichen Zeit keine anderen Änderungen einspielen.
Eine Sicherheits Version zu erstellen ist manchmal auch mit ein wenig Täuschung verwicklet. Das Projekt mag zum Beispiel an einer 1.1.3 Version gearbeitet haben, mit bestimmten Bug Fixes an 1.1.2 bereits öffentlich bekannt gegeben, wenn eine Sicherheitsmeldung eintrifft. Die Entwickler können natürlich nicht über das Sicherheitsproblem reden, bis sie den Fix zur Verfügung stellen; bis dahin, müssen sie weiter öffentlich so reden, als wäre 1.1.3 das, was die ganze Zeit geplant war. Wenn 1.1.3 aber wirklich erscheint, wird es sich von 1.1.2 nur durch die Sicherheits Fixes unterscheiden, und alle anderen werden auf die 1.1.4 aufgeschoben (wa jetzt natürlich auch den sicherheits Fix beinhalten wird, genau so wie alle zukünftigen Versionen).
Sie könnten eine weitere Komponente zu der bestehenden Version hinzufügen, welches darauf hindeutet, dass es nur sicherheits Änderungen beinhaltet. Zum Beispiel, könnte man alleine von den Zahlen erkennen, dass 1.1.2.1 eine Sicherheits Version von 1.1.2 ist, und sie würden wissen, dass jede "höhere" Version (d.h.1.1.3, 1.2.0, usw.) die gleichen sicherheits Fixes beinhaltet. Für solche die es wissen, teilt dieses System eine Menge Informationen mit. Andererseits, kann es ein wenig verwirrend sein, für diejenigen die das Projekt nicht so eng verfolgen, die meiste Zeit ein drei Komponenten System zu sehen, gelegentlich mit einer scheinbar zufällig reingeworfenen vierten Komponente. Die meisten Projekte die ich mir angeschaut hab, wählen Konsistenz und nehmen einfach die nächste geplante Nummer für sicherheits Versionen, selbst wenn das bedeutet, andere geplante Versionen um eins zu verschieben.