Kiedy deweloperzy danego projektu, podczas ciągłego rozwoju programu, dojdą do wniosku, że osiągnęli już kolejny punkt założeń projektowych, wydzielają w systemie kontroli wersji kolejną wersję minor i to w niej nanoszą zmiany, a linia poprzednia jest zamrożona i na nią nanoszone są jedynie poprawki istniejących tam błędów.
Często (np. w przypadku środowiska graficznego GNOME) praktykuje się przyjmowanie parzystych numerów minor jako linie stabilne projektu, a nieparzyste jako linie rozwojowe. Pozwala to na rozwijanie projektu w rozwojowej linii np. 2.9, a z punktem osiągnięcia założeń rozwojowych linii (zaimplementowania założonych funkcjonalności), numer wersji zostaje podbity do 2.10, oraz od razu zostaje wydzielona wersja 2.11 w której następuje dalszy rozwój, a na wersję 2.10 nanoszone są już tylko poprawki błędów (równolegle z linią 2.11). Pozwala to użytkownikom oprogramowania na używanie wersji stabilnych, bez niespodzianek, powstających naturalnie w wyniku rozwoju programu, a deweloperom na bezstresowe nanoszenie poprawek, bez obawy zepsucia programu u wszystkich.