Jeśli klasyczny schemat wersjonowania semantycznego „MAJOR.MINOR.PATCH” ma sens, zależy od tego, kogo wdrażasz, a zwłaszcza kiedy i jak często wdrażasz go do użytkownika końcowego . Schemat jest najbardziej użyteczny, jeśli pracujesz ze stabilnym wydaniem „4.5”, gdzie zaczynasz od wersji 4.5.0. Wersje 4.5.1, 4.5.2 itd. Zawierają tylko poprawki błędów, podczas gdy ty już wewnętrznie pracujesz nad wersją 4.6.
Na przykład, jeśli zapewnisz „stabilną gałąź” użytkownikowi końcowemu, daj jej wersję 4.5.0 dla początkowego wdrożenia oraz 4.5.1, 4.5.2, ilekroć wydasz łatkę. W swoim wewnętrznym „zwinnym” rozwoju i wdrożeniu w trakcie sprintu możesz już mieć wersję 4.6, po prostu nazwij ją „wersją beta”. Ilekroć wdrażasz go w trakcie sprintu, dodaj automatycznie generowany numer kompilacji, np. „4.6.beta kompilacja 123”. Po zakończeniu sprintu przypisz mu „4.6.0” i wewnętrznie zmień numer wersji następnego sprintu na „4.7”. Począwszy od „.0” to tylko konwencja, możesz także użyć „.0” do oznaczania wersji beta i zacząć od „.1” dla użytkowników końcowych. IMHO słowo „beta” jest znacznie bardziej wyraziste, mówiąc wszystkim, że sprint „jeszcze się nie zakończył”.
Jeśli wydasz pełny dziennik zmian dla użytkownika końcowego, a każda wersja beta zależy od Ciebie, ale przynajmniej na końcu sprintu dziennik zmian powinien zostać wypełniony, a za każdym razem, gdy dostarczysz poprawkę użytkownikowi końcowemu, powinieneś także zaktualizować dokumenty historyczne.
Znajdziesz strategię wypuszczenia dwóch oddzielnych gałęzi, jednej „stabilnej” gałęzi z semantycznymi numerami wersji i „gałęzi programistycznej” oznaczonej numerami kompilacji lub czymś podobnym, w wielu produktach typu open source, takich jak Inkscape, Firefox lub 7-zip.
Jeśli jednak nie pracujesz z oddzielnymi gałęziami stabilnymi i programistycznymi i codziennie wydajesz nową wersję użytkownikowi końcowemu, powinieneś również codziennie zwiększać numer wersji. W takim przypadku numery wersji „4.5.1”, „4.5.2”, ... prawdopodobnie odzwierciedlają Twoje indywidualne wdrożenia i nie wskazują różnicy między poprawkami błędów i innymi zmianami. To może być ok, to już nie jest już klasyczna „wersja semantyczna”. W tym scenariuszu można również wdrożyć wersje 4.5, 4.6, 4.7, 4.8, co nie daje żadnej różnicy.
Jeśli chodzi o twoje pytanie dotyczące wpisów w swoim dzienniku zmian: IMHO, gdy coś jest widoczne dla użytkownika końcowego, warto je wprowadzić w dzienniku zmian, jak tylko wdrożysz zmianę. Na przykład, jeśli użyjesz przełączania funkcji i wprowadzisz zmiany w częściowo wypalonej funkcji, która nie została jeszcze aktywowana dla użytkownika, nie należy ona do dziennika zmian. Jeśli dokonujesz tylko refaktoryzacji, bez widocznej zmiany dla użytkownika, nie należy to do dziennika zmian. Jeśli naprawisz błąd, który mógł mieć wpływ na niektórych użytkowników, zdecydowanie należy on do dziennika zmian - i należy o nim wspomnieć w tym samym czasie, gdy wdrażasz poprawkę. I nie ma znaczenia, czy wydajesz codziennie, miesięcznie czy corocznie.