Jedyny powód, dla którego etap 3.3.3 został oznaczony jako ukończony, to pozostawienie otwartego etapu przeszkadzało w naszych raportach dotyczących biletów dla 3.4.1. (Zapomniałem, że zamknięcia kamieni milowych znajdują odzwierciedlenie na osi czasu).
Ogólnie rzecz biorąc, przypisujemy bilety do następnego drobnego kamienia milowego, jeśli zgłaszają natychmiastową regresję. Tak więc regresja w 3.2, która pojawia się podczas opracowywania 3.3, zostałaby przypisana do 3.2.2, tak jak miało to miejsce tutaj. W tym przypadku posunęliśmy się tak daleko, że zamknęliśmy te bilety zatwierdzeniem względem oddziału 3.2. Robimy to czasami głównie ze względów porządkowych, więc jeśli istnieje potrzeba wydania, jesteśmy bardziej przygotowani. Ale ponieważ nic nie spowodowało wydania wersji 3.2.2 (wystarczająco krytyczny błąd lub coś związanego z bezpieczeństwem), właśnie zakończyliśmy kamień milowy. Jest to przydatne do celów śledzenia. Równie łatwo moglibyśmy go usunąć i ponownie przypisać wszystkie bilety do 3.3. Po prostu tego nie zrobiliśmy.
Edytuj, dodając więcej tła: Warto zauważyć, że zawsze staramy się, aby gałęzie wersji były jak najbardziej stabilne. Tak więc, jeśli korzystasz z gałęzi 3.2 i zawsze ją aktualizujesz, być może działasz coś „bardziej stabilnego” niż stabilne wydanie 3.2.1. Tego rodzaju dodatkowe poprawki często trafiają do gałęzi po wydaniu ostatniego punktu dla tej gałęzi, a zatem nie są wydawane.
Rzadko wydawaliśmy formalne pakiety - wersja 3.0.6 została wydana w tym samym czasie co wersja 3.1.2. Zasadniczo staraliśmy się utrzymać drugą najnowszą gałąź (np. 3.0), dopóki obecna gałąź programistyczna (np. 3.2) nie osiągnie statusu „beta”. Nie ogłosiliśmy dostępności wersji 3.0.6, ale każdy, kto prowadzi oddział 3.0, mógł przynajmniej zaktualizować te poprawki za pośrednictwem oficjalnych kanałów.