Najlepsze praktyki etykietowania wersji gier?

Czy ktoś wie, czy istnieje najlepsza praktyka oznaczania wersji gier.

Nie jestem pewien, czy istnieje standardowa nazwa inna niż wersja, ale mam na myśli w zasadzie:

• 1.0
• 1.1
• 1.2
• 1.3.1 beta

Nie ma standardu, ale powinieneś to zrobić w sposób, który jest dla ciebie sensowny i zawiera wszystkie informacje, które mogą być potrzebne do śledzenia tej kompilacji. Pracowałem dla firmy, która zasadniczo to zepsuła:

[Główny numer kompilacji]. [Mały numer kompilacji]. [Wersja]. [Pakiet]

tzn. wersja: 1.0.15.2

• Ważna wersja kompilacji : wskazuje na kamień milowy w grze, zwiększaj ją, przechodząc od wersji beta do wydania, od wydania do głównych aktualizacji.

• Niewielki numer kompilacji : używany do aktualizacji funkcji, dużych poprawek błędów itp.

• Rewizja : Drobne zmiany w istniejących funkcjach, drobne poprawki błędów itp.

• Pakiet : Twój kod pozostaje taki sam, zmiany w bibliotece zewnętrznej lub aktualizacja pliku zasobów.

Połączone zmiany przechodzą na najbardziej znaczącą zmianę. Na przykład, jeśli zwiększasz mniejszy numer kompilacji, zarówno wersja, jak i pakiet resetują się do 0.

Mimo że kategorie są zdefiniowane, nadal istnieje niejasność co do tego, jakie funkcje faktycznie przechodzą między wersją a niewielkim numerem kompilacji. To zależy od Ciebie. Jeśli utworzysz listę funkcji, które będą musiały zostać zaimplementowane przed każdym przyrostem, będziesz mieć również plan do naśladowania, ale ostatecznie to twoja decyzja, co pasuje do każdej kategorii.

Przepełnienie stosu ma świetną dyskusję na ten temat, jak na temat numerów wersji , która odwołuje się do Przewodnika stylu wersjonowania .

Podsumowanie:

• Wersja MAJOR, gdy dokonujesz niezgodnych zmian API
• Wersja MINOR, gdy dodajesz funkcjonalność w sposób kompatybilny wstecz
• Wersja PATCH po dokonaniu poprawek błędów kompatybilnych wstecz
• Dodatkowe etykiety metadanych w wersji wstępnej i kompilacji są dostępne jako rozszerzenia formatu MAJOR.MINOR.PATCH

O ile mi wiadomo, nie ma na to żadnego standardu. Praktyka będzie się różnić w zależności od firm, zespołów i projektów: nie ma czegoś takiego jak najlepsza praktyka. Najważniejsze nie jest faktyczna konwencja, ale fakt, że wszyscy się jej trzymają.

To powiedziawszy, wspomniany schemat jest dość powszechny w wydanych grach. 1.0 zwykle będzie złotym mistrzem, a od tego miejsca zaczną się łatki: 1.1, 1.2 ... Jest on również używany w wersjach dla klientów przedpremierowych, takich jak prywatne lub otwarte bety.

W przypadku gier w fazie rozwoju rzadko korzystałem z tego systemu. O wiele bardziej powszechne jest odwoływanie się do kompilacji poprzez jej identyfikator zmiany atomowej (np. Numer listy zmian Perforce). Jest to szczególnie przydatne w przypadku projektów na średnim poziomie, w których wszystko (kod i zasoby) jest przechowywane w tym samym repozytorium, a ciągła integracja ma miejsce. W takim przypadku posiadanie zarówno numeru zmiany atomowej, jak i numeru wersji jest zbędne i podatne na błędy. Niektóre kompilacje zostaną wyniesione na kamień milowy po kontroli jakości: alfa, beta, kandydat do wydania i jako takie oznaczone.

W przypadku dużych projektów prosta koncepcja „wersji gry” nie ma już zastosowania. Będziesz mieć kilka platform, jednostek SKU, języków, tryb dla pojedynczego gracza, tryb dla wielu graczy itp. Zarządzanie wersjami staje się wtedy pracą na pełen etat (czasami nazywany menedżerem danych - to terminologia Ubisoft, prawdopodobnie nazywana inaczej gdzie indziej) , schemat etykietowania jest wówczas znacznie bardziej złożony i wysoce zależny od rzeczywistej produkcji.