Dlaczego build.number jest „nadużyciem” wersji semantycznej?

Wyjaśniłem proponowany system kompilacji (Gradle / Artifactory / Jenkins / Chef) jednemu z naszych starszych architektów, a on skomentował mnie, z czym się nie zgadzam, ale nie mam wystarczającego doświadczenia, aby naprawdę się zastanowić.

Ten projekt tworzy bibliotekę Java (JAR) jako artefakt do ponownego wykorzystania przez inne zespoły. W przypadku wersji chciałbym zastosować podejście semantyczne:

<major>.<minor>.<patch>

Gdzie patchwskazuje na poprawki błędów / awaryjne, minorwskazuje wersje kompatybilne wstecz i majorwskazuje na ogromne refaktoryzacje interfejsu API i / lub zmiany niezgodne wstecz.

Jeśli chodzi o dostawę, to jest to, czego chcę: programista popełnia kod; powoduje to kompilację środowiska QA / TEST. Niektóre testy są uruchamiane (niektóre zautomatyzowane, niektóre ręczne). Jeśli wszystkie testy zakończą się pomyślnie, kompilacja produkcyjna opublikuje plik JAR w naszym wewnętrznym repozytorium. W tym momencie plik JAR powinien być odpowiednio wersjonowany, a moim pomysłem było użycie tego, build.numberktóry jest automatycznie generowany i udostępniany przez nasze narzędzie CI, aby działał jako numer poprawki.

Tak więc wersjonowanie byłoby w rzeczywistości:

<major>.<minor>.<build.number>

Znów, gdzie build.numberzapewnia narzędzie CI.

Architekt odrzucił to, mówiąc, że użycie numeru kompilacji CI było „nadużyciem” wersjonowania semantycznego.

Moje pytanie brzmi: czy jest to poprawne, a jeśli tak, to dlaczego? A jeśli nie to dlaczego nie?

continuous-integration versioning builds continuous-delivery semantic-versioning herpylderp
źródło

Odpowiedzi:

Twój numer kompilacji nie zostanie zresetowany do zera, gdy wzrost wersji mniejszej i większej, narusza to sekcje 7 i 8 specyfikacji :

Niewielka wersja Y (xYz | x> 0) MUSI być zwiększana, jeśli do publicznego interfejsu API zostanie wprowadzona nowa funkcjonalność zgodna z poprzednimi wersjami. MUSI być zwiększany, jeśli jakakolwiek publiczna funkcja API jest oznaczona jako przestarzała. MOŻE zostać zwiększona, jeśli w kodzie prywatnym zostaną wprowadzone znaczące nowe funkcje lub ulepszenia. MOŻE obejmować zmiany poziomu łatek. Wersja poprawki MUSI zostać zresetowana do 0, gdy wersja pomniejsza zostanie zwiększona.

Wersja główna X (Xyz | X> 0) MUSI być zwiększana, jeśli jakiekolwiek publiczne wstecznie niezgodne zmiany zostaną wprowadzone do publicznego API. MOŻE obejmować niewielkie zmiany i zmiany poziomu łatek. Łatka i wersja pomocnicza MUSZĄ zostać zresetowane do 0, gdy wersja główna jest zwiększana.

Dlatego numery wersji (główna, drobna, łatka) należy podać ręcznie, ponieważ służą one do informowania użytkowników o zmianach w jednym miejscu bez konieczności patrzenia na dziennik zmian lub inny dokument.

Jeśli chcesz dołączyć numer kompilacji, możesz dołączyć je po +(sekcja 10):

Metadane kompilacji MOGĄ być oznaczone poprzez dodanie znaku plus i szeregu identyfikatorów oddzielonych kropkami bezpośrednio po łatce lub wersji wstępnej. Identyfikatory MUSZĄ zawierać tylko znaki alfanumeryczne ASCII i łącznik [0-9A-Za-z-]. Identyfikatory NIE MOGĄ być puste. Metadane kompilacji POWINNY być ignorowane podczas określania pierwszeństwa wersji. Dlatego dwie wersje, które różnią się tylko metadanymi kompilacji, mają taki sam priorytet. Przykłady: 1.0.0-alfa + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Pozostałość
źródło

Szybkie śledzenie @Residuum (i BTW +1 za odpowiedź): czy numery wersji należy zawsze zawsze wyprowadzać ręcznie? Jeśli nie, to jakich narzędzi można użyć zamiast CI / numeru kompilacji?

herpylderp

@herpylderp wcale nie, „specyfikacja” Toma Prestona-Wernera to tylko jego opinia, mnóstwo innych firm ma różne (ogólnie bardzo do siebie podobne) standardy. W większości z nich automatycznie generowany numer jest częścią wersji. Użycie numeru kompilacji CI jest rozsądne.

gbjbaanb

Nadal możesz używać narzędzia CI, jeśli narzędzie pozwala wykonywać arytmetykę liczb kompilacji. Bez względu na to, jaką wersję wydasz jako główne lub drobne uaktualnienie wersji, podłącz ten numer kompilacji do wyrażenia dla ciągu wersji odejmującego od bieżącego numeru kompilacji CI. Voila, właśnie zresetowałeś numer kompilacji do zera dla nowej wersji, bez faktycznego resetowania numeru kompilacji.

KeithS

Jeśli chodzi o mnie, używam po prostu [głównych]. [Mniejszych]. [Wersji]. [Wersji SVN] dla bibliotek DLL i [głównych]. [Mniejszych]. [Wersji SVN] dla instalatorów. Numer kompilacji CI służy wyłącznie do użytku wewnętrznego, aby pokazać, gdzie kompilacja, która się nie powiodła, mogła zostać ponownie uruchomiona z dokładnie tą samą bazą kodu po zmianie w środowisku CI (instalowanie certyfikatu klucza, dodawanie wspólnych bibliotek do GAC itp.).

KeithS

@gbjbaanb i wsp .: W każdej dyskusji na temat „wersji semantycznej”, w której uczestniczyłem, tematem była semver.org . Szukaj w Internecie pod kątem „semantycznej wersji”, a przynajmniej na pierwszej stronie pojawią się plusy / minusy dotyczące definicji z semver.org . Możesz używać własnych schematów wersjonowania, ale nie nazywaj go wersjami semantycznymi, ponieważ termin ten jest jasno zdefiniowany.

Residuum

Jednym z powodów jest to, że łatka może wymagać kilku kompilacji, więc jeśli masz wersję 5.7 i chcesz ją załatać do 5.7.1, ale pierwsze 2 poprawki błędów nie kompilują się, gdy zostaną przesłane do systemu CI, to będziesz o 5.7.3 przed wydaniem pierwszej łatki!

Odpowiedzią jest po prostu użycie 4 cyfr (jak zwykle w systemach Microsoft). Czwarty jest numerem kompilacji i jest używany „wyłącznie w celach informacyjnych”. Zasadniczo ludzie umieszczają tam numer wersji repozytorium (jeśli używają SVN, TFS lub podobnego), co jest naprawdę miłe, ponieważ można sprawdzić, które dokładne zatwierdzenie zostało użyte do zbudowania plików binarnych. Jeśli nie masz czegoś takiego, numer kompilacji CI jest rozsądnym przybliżeniem (można mieć nadzieję, że twój system CI zapamięta numery kompilacji i powiąże go z historią repo, ale nie jesteś zależny od CI system zapamiętuje je - nigdy nie możesz usunąć starych kompilacji).

Należy zauważyć, że schemat Microsoft do wersjonowania używa trzeciej pozycji dla numerów kompilacji. Chrome używa tylko 1 cyfry. Ubuntu używa daty. Nie ma „standardu” do użycia , z tym wyjątkiem, że wszystkie liczby muszą się zwiększać.

gbjbaanb
źródło

Chociaż nie ma standardu powszechnie używanego lub egzekwowanego, wydaje się, że pytanie dotyczy konkretnie wersji semantycznej, która ma specyfikację.

Doval

Nawet to jest zepsute w terenie, na przykład wersja NuGet Microsoftu używa semver, w sposób zepsuty (używając stylu wersji wstępnej dla numerów kompilacji), a Ruby używa major.minor.teeny.patch . W każdym razie, ponieważ numer kompilacji może być częścią semver, architekt mówił tosh (choć wprawdzie powinien to być + build, a nie na 3. pozycji).

gbjbaanb

Specyfikacja SemVer 2.0 pochodzi z 2013 roku, a specyfikacja 1.0 pochodzi z 2012 roku, o ile wiem. Prawdopodobnie NuGet i Ruby robili swoje, zanim pojawiła się specyfikacja. To nie jest tak, że specyfikacja SemVer jest nowością; po prostu formalizuje to, co ludzie już robili, więc wszyscy możemy ostatecznie uzgodnić jeden sposób, aby to zrobić zamiast kilkunastu odmian.

Doval

„masz wersję 5.7 i chcesz ją załatać do wersji 5.7.1, ale twoich pierwszych 2 błędów nie można skompilować po przesłaniu ich do systemu CI, wtedy będziesz w wersji 5.7.3 przed wydaniem pierwszej poprawki ! ” ok, ale co z tego? W semver nie przypominam sobie, że liczby nie mogą pomijać.

Andy