Czy wersja semantyczna pozwala na 4 komponenty w numerach wersji?

Wszystkie przykłady wersji semantycznej, które widziałem, pokazują 3 używane komponenty. Nie więcej niż 2 znaki kropki. W $DAYJOBnaszych numerach wersji używamy 4 komponentów:

5.0.1.2

Czy pozwala na to wersja semantyczna?

A czy jako pytanie dodatkowe na wyższym poziomie i bardziej dyskusyjne, czy to w ogóle ma znaczenie? Zacząłem myśleć, że dobrym pomysłem może być wymuszenie wersjonowania semantycznego, ale ostatecznie podmioty takie jak PCI go nadpisują.

Powinienem był wyjaśnić mój komentarz dotyczący PCI. Problem polega na tym, że audyty i ich koszty wpływają na zmianę głównych i mniejszych komponentów, niekoniecznie jest to prawdziwa nowa funkcja. Na przykład, jeśli wprowadzona zostanie funkcja związana z płatnościami, podbijamy mniejszy numer dla PCI. Ale jeśli dodamy zupełnie nową funkcję związaną z czymś w gui, tak się nie stanie. Zmienia się tylko łatka. Więc w tym przypadku tak naprawdę nie mamy nic do powiedzenia w tej sprawie jako deweloperzy, ponieważ ktoś inny podejmuje te decyzje.

versioning semantic-versioning pci

— void.pointer
źródło

Wersje semantyczne to wytyczne. Skąd PCI państwo coś o tym, jak rzeczy mają być wersjami?

— void.pointer

@ void.pointer czy możesz podać przykład, dlaczego używasz czwartego komponentu? Czy używasz go w zasadzie do ominięcia wewnętrznych kosztów i struktur księgowych - pozwalając zespołowi śledzić nowe funkcje bez zwiększania liczby łatek?

— kraina krańca

@enderland Tak w zasadzie. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. Zasadniczo wolno nam zmieniać tylko trzeci i czwarty komponent bez angażowania PCI (a następnie panów PCI w firmie). Wydaje mi się, że jest to nieco wymyślone, nie jestem pewien, czy są uzasadnione w sposobie zarządzania numerem wersji, ale nie wiem wystarczająco dużo o PCI i procesie audytu, aby powiedzieć inaczej.

— void.pointer

Używamy również 4 grup, a nie 3. Dlaczego? Ponieważ C ++. C ++ ma binarną kompatybilność wsteczną i źródłową kompatybilność wsteczną: pierwsza implikuje druga, ale relacja nie jest symetryczna. Dlatego używamy czwartej grupy do kompatybilności binarnej (możesz załatać system na gorąco) i trzeciej do kompatybilności źródła (musisz ponownie skompilować, ale nie powinieneś modyfikować własnego kodu). I wiesz co, to działa dla nas!

— Matthieu M.

Odpowiedzi:

Wygląda na to, że omijasz normalne konwencje tylko po to, aby uniknąć narzutu procesu / audytów. To ... wydaje mi się niepokojące.

To, co robisz, polega na celowym tworzeniu dodatkowego numeru wersji (twojej mniejszej cyfry PCI), nieco celowo, aby przenieść swoje funkcje / drobne numery wersji z powrotem o miejsce, aby nie uruchamiać kryteriów kontroli wewnętrznej.

W każdym razie, przechodząc do pytania na temat wersji semantycznej, specyfikacja dla wersji semantycznej mówi:

Biorąc pod uwagę numer wersji MAJOR.MINOR.PATCH, zwiększ:

Wersja MAJOR, gdy dokonujesz niezgodnych zmian API,

Wersja MINOR, gdy dodajesz funkcjonalność w sposób kompatybilny wstecz, oraz

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 .

Podkreśl moje.

Pytanie brzmi: czy używasz czwartego znaku do metadanych przedpremierowych / kompilacyjnych? Czy jest to w zasadzie kolejna wersja wskazująca na wydanie?

Jeśli „tak”, specyfikacja wersji semantycznej na to pozwala. Jeśli „nie”, to technicznie nie przestrzegasz wersji semantycznej.

A czy jako pytanie dodatkowe na wyższym poziomie i bardziej dyskusyjne, czy to w ogóle ma znaczenie?

To, czy chcesz ściśle go przestrzegać, czy nie, jest decyzją, którą Ty i Twój zespół musicie podjąć. Wersja semantyczna ma na celu pomóc w kompatybilności API:

Poprawki błędów, które nie wpływają na interfejs API, zwiększają wersję poprawki, kompatybilne wstecz dodatki / zmiany API zwiększają wersję mniejszą, a wstecznie niezgodne zmiany API zwiększają wersję główną.

Nazywam ten system „wersją semantyczną”. W ramach tego schematu numery wersji i sposób ich zmiany przekazują znaczenie dotyczące kodu źródłowego i tego, co zostało zmodyfikowane z jednej wersji do następnej.

Jest to system, który pomaga wyjaśnić, kiedy przechowywanie wersji wpływa na dalszych użytkowników interfejsu API.

Dopóki twój interfejs API jest podobnie jasny, nie jest to wielka sprawa, którą wybierzesz. Wersje semantyczne po prostu okazują się proste, na przykład, jeśli korzystam z wersji 3.4.2 i muszę zaktualizować do wersji 3.4.10, wiem, że mogę to zrobić, nie psując niczego. Jeśli nowa wersja to 3.5.1, wiem, że jest kompatybilna wstecz. I wiem, że wersja 4.0.1 byłaby przełomową zmianą.

To wszystko jest częścią znaczenia numerów wersji.

@enderland Tak w zasadzie. MAJOR (PCI) .MINOR (PCI) .EATURE.HOTFIX + BUILD. Zasadniczo wolno nam zmieniać tylko trzeci i czwarty komponent bez angażowania PCI (a następnie panów PCI w firmie). Wydaje mi się, że jest to nieco wymyślone, nie jestem pewien, czy są uzasadnione w sposobie zarządzania numerem wersji, ale nie wiem wystarczająco dużo o PCI i procesie audytu, aby powiedzieć inaczej.

Okej, w porządku. Masz system, który działa dla Ciebie i spełnia Twoje potrzeby. To jest kwestia wersjonowania.

Jeśli Twój interfejs API jest prywatny (tylko wewnętrznie), tak naprawdę nie ma znaczenia, w jaki sposób korzystasz z wersji, o ile ma to sens dla Ciebie i wszystkich osób korzystających z niego. Wersje w standardowym formacie mają znaczenie, gdy masz wielu innych użytkowników interfejsu API, którzy muszą wiedzieć „co oznacza ta wersja?”

Posiadanie dowolnego systemu wersjonowania wprowadzi w błąd osoby przyzwyczajone do innych systemów, takich jak wersja semantyczna. Ale jeśli nikt tak naprawdę nie używa twojego systemu kontroli wersji, z wyjątkiem osób, które go tworzą - to nie ma znaczenia.

— kraina krańca
źródło

Jeśli chodzi o twoją edycję na górze: pozwól, że zagram tutaj w adwokata diabła. Audyty PCI kosztują pieniądze firmy i nie każda wdrożona funkcja ma dla nich znaczenie. Dlaczego więc ponosić koszty i inne koszty ogólne na samych zasadach? Dlaczego to tak niepokoi? Zdaję sobie sprawę, że metoda ustalania kontroli jest prawdopodobnie wadliwa, ale rozdzielenie obaw wydaje się rozsądne. Rzeczy niezwiązane zdalnie z przetwarzaniem kart nie mają znaczenia dla PCI.

— void.pointer

@ void.pointer Nie jestem w stanie ocenić, dlaczego / jak ustalane są twoje audyty. Ale ktoś zdecydował, że chce przeprowadzić audyt na podstawie określonych kryteriów. Celowe pominięcie tych kryteriów kontroli wydaje się niepokojące (niezależnie od tego, ile zaoszczędzisz, robiąc to).

— Enderland

@ void.pointer, kraina krańców ma rację. Jeśli terrorysta grozi zabiciem twojej rodziny, jeśli twoje wersje nie składają się wyłącznie z liter alfabetu, prawdziwym problemem jest terrorysta. Nie krępuj się stosować wersjonowania semantycznego, aby go obejść (w rzeczywistości zdecydowanie sugerowałbym to w tym przypadku), ale tak naprawdę jest to: obejście wymagane przez inny problem.

— Paul Draper,

@PaulDraper Kiedy semver stał się jedyną prawdziwą drogą do wersji?

— Andy

@Andy, nie zrobił. OP zapytał o SemVer. IDK dlaczego, ale tak właśnie zrobił.

— Paul Draper,

W obecnej wersji Semantic Versioning, czyli 2.0.0 , nie. Istnieje wymóg, który definiuje wersję jako formę XYZ, gdzie X, Y i Z są liczbami całkowitymi nieujemnymi, które nie zawierają wiodących zer:

Normalny numer wersji MUSI przyjąć postać XYZ, gdzie X, Y i Z są liczbami całkowitymi nieujemnymi i NIE MUSZĄ zawierać zer wiodących. X to wersja główna, Y to wersja pomniejsza, a Z to wersja łatki. Każdy element MUSI rosnąć liczbowo. Na przykład: 1.9.0 -> 1.10.0 -> 1.11.0.

Jednak możliwość dodawania metadanych jest dozwolona dla:

Metadane kompilacji MOGĄ być oznaczone przez dodanie znaku plus i szeregu identyfikatorów oddzielonych kropkami bezpośrednio po aktualizacji 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. Zatem 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.

Należy jednak zauważyć, że wersja semantyczna jest przeznaczona specjalnie dla oprogramowania, które deklaruje publiczny interfejs API:

Oprogramowanie korzystające z wersji semantycznej MUSI zadeklarować publiczny interfejs API. Ten interfejs API może zostać zadeklarowany w samym kodzie lub istnieć wyłącznie w dokumentacji. Jakkolwiek się to stanie, powinno być precyzyjne i kompleksowe.

Ma to tendencję do wspierania rozwoju bibliotek lub usług, a nie na poziomie aplikacji.

Ważną rzeczą do rozważenia jest to, co oznaczają twoje numery wersji, zarówno do użytku wewnętrznego, jak i zewnętrznego. Wersje to tylko identyfikatory, które pozwalają mówić o różnicach w oprogramowaniu w dwóch różnych momentach. Wersje semantyczne to jedna z metod owijania reguł, więc jeśli wiesz, że aplikacja korzysta z wersji semantycznej, możesz łatwiej określić poziom wysiłku wymaganego do aktualizacji pakietów. Przestrzeganie wspólnego standardu może być dobre, ale jeśli nie możesz z jakiegokolwiek powodu, dokumentowanie reguł dla użytkowników również powinno być wystarczające.

— Thomas Owens
źródło

+1 za publiczną notatkę API. Nie mamy publicznego interfejsu API, ale możemy przełamać kompatybilność wsteczną w innych aspektach, takich jak dane. Możliwe, że wysyłamy kompilację instalowaną na starych wersjach, ale dane się nie zmieniają i nie jesteśmy już w stanie odczytać tych danych (zazwyczaj obsługujemy jednak stare formaty)

— void.pointer