Co naprawdę oznaczają wersje aktualizacji?

Wiele aktualizacji oprogramowania jest zgodnych ze schematem od v0.1 do v0.2 do v2.6.5.6 . Co tak naprawdę oznaczają te „aktualizacje” oprogramowania? Czy zawsze przestrzegany jest standard branżowy, czy programiści wciąż podnoszą aktualizację # lub dodają więcej miejsc po przecinku?

Jak powiedział Shaun, tak naprawdę nie ma standardu. Niektóre firmy stosują lepsze praktyki wersjonowania niż inne (miałem do czynienia z dostawcami, którzy pomijają główne numery wersji, a inni utknęli na tym samym xy kilka wydań później).

Powiedziawszy to, wynalazca Gravatars i współzałożyciel GitHub ( Tom Preston-Werner ) jest autorem dokumentu do „ Semantic Versioning ”, który jest więcej niż wart przeczytania.

Oto wyjątkiem wstępu:

Jako rozwiązanie tego problemu proponuję prosty zestaw reguł i wymagań, które określają sposób przypisywania i zwiększania numerów wersji. Aby ten system działał, musisz najpierw zadeklarować publiczny interfejs API. Może to obejmować dokumentację lub być egzekwowane przez sam kod. Niezależnie od tego ważne jest, aby ten interfejs API był jasny i precyzyjny. Gdy zidentyfikujesz swój publiczny interfejs API, komunikujesz zmiany w nim z określonymi przyrostami numeru wersji. Rozważ format wersji XYZ (Major.Minor.Patch). 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.

4 cyfry to zwykle MajorV.MinorV.PatchNum.BuildNum, przynajmniej tam, gdzie pracuję.

Osobiście wolę schemat wersjonowania Ubuntu - znacznie ułatwia życie.

Krótka wersja jest taka, że ​​nie ma standardu, a firmy robią, co chcą. Zasadniczo im więcej liczb masz, tym mniejsza liczba zmian reprezentuje każda liczba. Zwykle zobaczysz co najmniej wersję xy, gdzie xa x oznacza główne wydania (główne ulepszenia / rozszerzenia funkcji), a y oznacza drobne wydania (znaczące poprawki lub poprawki błędów). Więcej miejsc po przecinku po tych dwóch może oznaczać różne rzeczy wewnętrznie dla firmy, chociaż często dotyczą mniejszych kompilacji treści lub łatek, które reprezentują szybsze i mniejsze poprawki.

Wikipedia ma artykuł, który opisuje to bardziej szczegółowo.

Numery wersji służą jako odniesienie do raportów problemów. Jedynym wymaganiem jest to, aby każde wydanie miało unikalny numer wersji. Niektóre liczby są napędzane przez marketing - większe liczby całkowite są łatwiejsze do sprzedania, a liczby mocy takie jak 10 (rzymska X) są naprawdę chwytliwe. Niektóre osoby używają pewnej odmiany semantycznej wersji:

MAJOR.MINOR.MICRO.BUILD

• Główne przyrosty: niezgodne zmiany lub całkowite przeprojektowanie interfejsu użytkownika
• Niewielkie przyrosty: dodano nowe funkcje, zgodne z wcześniejszymi wersjami o tym samym głównym numerze wersji
• Przyrosty mikro: wydanie poprawki błędu
• Numer kompilacji: wygenerowany przez kompilator lub pobrany z kontroli wersji

Wiele grup upuszcza numer BUILD w swoich wydaniach. Jest to zwykle przydatne tylko między grupami testującymi i programistycznymi.

Niektóre grupy dodają dodatkową semantykę, na przykład nieparzyste przyrosty MINOR dla eksperymentalnych kompilacji, a parzyste przyrosty MINOR dla wydań produkcyjnych ( jądro Linux używa tego podejścia).

Najważniejsze jest to, że nie ma standardu, inne niż nowsze wersje używają wyższych numerów wersji i że każdy numer wersji jest unikalny.