Kiedy zatwierdzenie nie powinno być oznaczane wersją?

30

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).

VortixDev
źródło
23
Czy każde zobowiązanie do opanowania stabilnego, przetestowanego, zapewniającego jakość wydania w twoim projekcie?
Alex Reinking
1
@AlexReinking Każde zatwierdzenie jest testowane, ale po prostu próbuję przyzwyczaić się do typowych praktyk z moimi osobistymi projektami, więc to tylko ja pracuję i jako taki tak naprawdę nie ma systemu innego niż „dokonaj zmiany, przetestuj to sam, popełnij to ”.
VortixDev
Pamiętaj też, że tagi można później zmienić. Jedynym solidnym identyfikatorem zatwierdzenia jest klucz skrótu zatwierdzenia.
Thorbjørn Ravn Andersen
9
każde zobowiązanie do opanowania ??? nigdy nie powinieneś zobowiązać się do opanowania. Każde połączenie do opanowania brzmi o wiele lepiej.
xyious
2
Myślę, że @xyious uderza w sedno. Każde zatwierdzenie, które kończy się na wzorcu, powinno być oznaczone wersją, ponieważ każde zatwierdzenie na wzorcu powinno być połączeniem wydania z develop .
BJ Myers

Odpowiedzi:

71

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.

Alex Reinking
źródło
5
SemVer ma sens głównie w przypadku bibliotek, w których użytkownik to inne fragmenty kodu, a nie ludzie. Naprawdę nie ma żadnych „przełomowych” zmian w większości aplikacji zorientowanych na użytkownika, ponieważ użytkownik może automatycznie dostosować się do nowej wersji.
Qwertie
5
Argumentowałbym, że wersje wiersza poleceń aplikacji skierowanych do użytkownika powinny być wersjonowane semantycznie, ponieważ ich flagi i formaty wyjściowe mogą zachowywać się inaczej. Trochę szarej strefy.
Alex Reinking
5
@Qwertie Oczekiwania użytkowników są mniej sztywne niż oczekiwania dotyczące oprogramowania, ale nadal istnieją. OSTATECZNIE użyłem wielu programów, które wydały coś, co uważam za „przełomowe” zmiany w ich interfejsie lub funkcjonalności. Decyzja o tym, co stanowi wydanie główne w porównaniu z wydaniem niewielkim, jest z pewnością bardziej subiektywna niż w przypadku bibliotek, ale niekoniecznie jest to powód, aby tego unikać.
Żelazo Gremlin
11
@Qwertie - wstrzymaj aktualizację. Ile osób nadal używa starych głównych wersji systemu Windows i pakietu Office?
Alex Reinking
5
@Qwertie Mogą być zainspirowani do uważnego przeczytania dziennika zmian lub dokumentacji, aby mogli dostosować sposób korzystania z systemu do korzystania z nowych lub zmodyfikowanych funkcji lub znaleźć obejścia funkcji, która została usunięta. Jest to ten sam przypadek, ich użycie oprogramowania musi się zmienić, ponieważ oprogramowanie się zmieniło, więc powinieneś jednoznacznie powiedzieć im o tej zmianie.
Żelazo Gremlin
11

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.

Peter Green
źródło
2

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ść.

ANone
źródło
0

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ę.

xyious
źródło