Kiedy zatwierdzenie nie powinno być oznaczane wersją?

Kontekst: Niedawno dowiedziałem się o wersji semantycznej i próbuję ustalić, jak najlepiej wykorzystać ją praktycznie do własnych projektów.

Biorąc pod uwagę, że semver bierze pod uwagę duże zmiany, drobne zmiany i łatki dla wersji, kiedy zatwierdzenia nie należy oznaczać zaktualizowaną wersją? Wydaje mi się, że każda zmiana zmieściłaby się w jednej z tych kategorii, dlatego każda zmiana powinna być wersjonowana, ale kiedy patrzę na różne popularne projekty w GitHub, nie wydaje się, że tak to się robi (po prostu patrząc na fakt, że duże projekty mają dziesiątki tysięcy zatwierdzeń, z tylko setkami tagów).

SemVer obawy wersjonowania komunikaty , nie popełnia . Jeśli twój model kontroli wersji wymaga, aby każde zatwierdzenie do opanowania było wydaniem, wtedy tak, każde zatwierdzenie będzie musiało być otagowane zgodnie ze stopniem zmiany.

Generalnie jednak projekty opracowują głównie stabilny produkt na platformie master i oznaczają wydania, które uznają za warte wsparcia. Kiedy to zrobią, będą tagować zgodnie ze schematem wersjonowania, który niekoniecznie musi być w szczególności SemVer.

Numery wersji są przydzielane do wydań. Zasadniczo nie każde zatwierdzenie powinno być wydaniem. Jest tego kilka przyczyn.

Po pierwsze, kiedy mówisz, że „testujesz” każde zatwierdzenie, istnieją poziomy testowania. Uruchamianie zautomatyzowanego oprogramowania testowego na jednym komputerze jest dobre i dobre, ale w złożonym oprogramowaniu prawdopodobnie nie wykryje każdego problemu. Niektóre problemy mogą dotyczyć sprzętu lub konfiguracji, inne mogą dotyczyć bardziej subiektywnych względów ludzkich niż trudnych do przetestowania wymagań.

Po drugie, wybicie głównego numeru wersji powinno być rzadkim działaniem. Zasadniczo oznacza to, że wszystko, co zależy od oprogramowania, musi zostać ręcznie sprawdzone, aby sprawdzić, czy zależy to od którejkolwiek z usuniętych funkcji.

Konsekwencją tego jest to, że należy dodawać funkcje do „publicznych interfejsów API” w pełnych wersjach (nie w wersji alfa / beta), jeśli jesteś przygotowany do obsługi tych funkcji w ich obecnej formie długoterminowej.

Po trzecie, pomocne jest ograniczenie liczby powszechnie używanych wersji. Nawet w stabilnej gałęzi często lepiej jest zebrać razem kilka poprawek i wydać jedno wydanie niż wydanie dla każdej poprawki.

Wydaje się to oczywiste, ale: celem numerów wersji jest umożliwienie łatwego określenia, jakiej wersji oprogramowania używa każdy użytkownik.

Jeśli istnieje jakakolwiek szansa, że ​​ktokolwiek będzie miał dostęp do określonej iteracji kodu, a poza tym nie będzie w stanie łatwo ustalić niepowtarzalnego identyfikatora, to ta iteracja powinna mieć unikalny numer wersji. Widzę to jako „pierwszą zasadę”. W związku z tym różne wersje będą wyraźnie chciały mieć różne numery wersji.

W grę wchodzi jednak więcej:

Jednym ze sposobów, aby być tego pewnym, jest wybijanie numerów wersji przy każdym zatwierdzeniu, ale zwykle nie jest to dobry pomysł. Wykonanie stosunkowo niewielkiej zmiany może zająć kilka zatwierdzeń / iteracji, a wprowadzanie w życie świata zewnętrznego mylące jest, gdy zobaczysz wersję 0.0.1 -> 0.0.2 w wyniku dużej liczby skumulowanych zmian, a następnie 0.0.2 -> 0.0 .56, ponieważ ktoś popełnił spację naprawiając jeden plik na raz i nie zmienił niczego funkcjonalnego.

To, jak daleko od „jednej wersji na pełne wydanie” do „jednej wersji dla każdego zatwierdzenia”, zależy naprawdę: od ciebie, od innych użytkowników i od systemów, których chcesz użyć, aby wypełnić luki.

Osobiście jestem przyzwyczajony do pracy nad małymi projektami i cieszę się, że używam haszów git do wersji, z której korzystają inni, i wersji wypukłej dla każdego z nich (bez względu na to, jak niewielu ludzi oczekuję, że to zrobią). Jednak w większych firmach i większych projektach stosuje się coś poza numerami wersji semantycznych, ale niższą wierność niż w każdym zatwierdzeniu, jak na przykład numeracja kandydatów do wydania. Są to zalety, ale zwiększają złożoność.

Każde żądanie ściągnięcia, które zostanie scalone z master, powinno być wersjonowane.

Jeśli nie powinna to być nowa wersja (przynajmniej łatka), prawdopodobnie nie powinna zostać scalona z master, ponieważ funkcja / fix / etc nie jest kompletna.

Jednak w zależności od przepływu pracy Twojego zespołu nadal możesz uzyskać wiele zatwierdzeń bez wersji. Jeśli w żądaniu ściągania jest kilka zatwierdzeń, które nie są zgniecione (moim zdaniem nie powinny), nadal możesz otrzymać 10 zatwierdzeń i tylko 1 nową wersję.