Co zwykle oznaczają liczby w wersji (np. Wersja 1.9.0.1)?

Może to głupie pytanie, ale zawsze zakładałem, że każda liczba wyznaczona kropką reprezentuje pojedynczy element oprogramowania. Jeśli to prawda, czy kiedykolwiek reprezentują coś innego? Chciałbym zacząć przypisywać wersje do różnych wersji mojego oprogramowania, ale nie jestem pewien, jak powinno być zbudowane. Moje oprogramowanie składa się z pięciu różnych komponentów.

W wersji 1.9.0.1 :

• 1 : Duża zmiana (nowy interfejs użytkownika, wiele nowych funkcji, zmiana koncepcyjna itp.)

• 9 : Niewielka zmiana (może zmiana w polu wyszukiwania, dodana 1 funkcja, zbiór poprawek błędów)

• 0 : wydanie poprawki błędów

• 1 : Numer kompilacji (jeśli jest używany) - dlatego widzisz, że platforma .NET używa czegoś takiego jak 2.0.4.2709

Nie znajdziesz wielu aplikacji z czterema poziomami, zazwyczaj wystarcza 3.

Istnieje specyfikacja wersjonowania semantycznego

Oto podsumowanie wersji 2.0.0:

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

1. GŁÓWNA wersja w przypadku niekompatybilnych zmian API,
2. MNIEJSZA wersja, gdy dodasz funkcje w sposób kompatybilny wstecz i
3. Wersja PATCH po wprowadzeniu poprawek zgodnych wstecz.

Dodatkowe etykiety metadanych w wersji wstępnej i kompilacji są dostępne jako rozszerzenia formatu MAJOR.MINOR.PATCH.

Może być bardzo arbitralny i różni się w zależności od produktu. Na przykład w dystrybucji Ubuntu 8.04 odnosi się do kwietnia 2008 r

Zazwyczaj skrajne lewe (główne) liczby wskazują główne wydanie, a im dalej w prawo, tym mniejsza jest zmiana.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Im więcej punktów, tym mniejsze wydanie. Poza tym nie ma prawdziwego standardu - może oznaczać różne rzeczy w zależności od tego, na co zdecydują opiekunowie projektu.

Na przykład WordPress działa w następujący sposób:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

Wersja 1.6 do 2.0 byłaby dużym wydaniem - funkcje, zmiany interfejsu, poważne zmiany w interfejsach API, awaria niektórych szablonów i wtyczek w wersji 1.6, itp. Wersja 2.0 do 2.0.1 byłaby drobną wersją - być może naprawiającą błąd bezpieczeństwa. Wersja 2.0.2 do 2.1 byłaby znaczącą wersją - ogólnie rzecz biorąc, nowe funkcje.

Liczby mogą być przydatne w sposób opisany w innych odpowiedziach, ale zastanów się, dlaczego mogą być one również bez znaczenia ... Sun, wiesz SUN, java: 1.2, 1.3, 1.4 1.5 lub 5, a następnie 6. W starej, dobrej wersji Apple II Numery Coś. W dzisiejszych czasach ludzie rezygnują z numerów wersji i używają głupich nazw, takich jak „Figowiec zadziorny” (lub coś w tym rodzaju), „czapla odporna”, „europa” i „ganimedes”. Oczywiście jest to znacznie mniej przydatne, ponieważ zabraknie ci księżyców Jowisza, zanim przestaniesz zmieniać program, a ponieważ nie ma oczywistego porządku, nie możesz powiedzieć, który jest nowszy.

W wersji v1.9.0.1: Jest to jawny schemat wersjonowania używany, gdy nie chcesz używać nazwy dla wersji wstępnych lub budować jak -alpha, -beta.

1: Główna wersja, która może naruszyć wsteczną kompatybilność

9: Dodanie nowych funkcji wspierających Twoją aplikację wraz z kompatybilnością wsteczną z poprzednią wersją.

0: kilka drobnych poprawek błędów

1: Numer kompilacji (numer wersji wstępnej)

ale obecnie nie znajdziesz takiego schematu wersjonowania. Zobacz wersjonowanie semantyczne [semver2.0] https://semver.org/

Numery wersji zwykle nie reprezentują oddzielnych składników. Dla niektórych osób / oprogramowania liczby są dość arbitralne. Dla innych różne części ciągu numeru wersji reprezentują różne rzeczy. Na przykład niektóre systemy zwiększają część numeru wersji, gdy zmienia się format pliku. Zatem V 1.2.1 jest formatem plików zgodnym ze wszystkimi innymi wersjami V 1.2 (1.2.2, 1.2.3 itd.), Ale nie z V 1.3. Ostatecznie to od Ciebie zależy, jakiego schematu chcesz użyć.

Zwykle jest to:

MajorVersion.MinorVersion.Rvision.Build

To zależy, ale typowa reprezentacja to major.minor.release.build .

Gdzie:

• poważny to główna wersja oprogramowania, pomyśl .NET 3.x
• minor to drugorzędna wersja twojego oprogramowania, pomyśl .NET x.5
• release to wydanie tej wersji, zazwyczaj poprawki błędów będą to zwiększać
• build to liczba oznaczająca liczbę wykonanych kompilacji.

Na przykład 1.9.0.1 oznacza, że ​​jest to wersja 1.9 twojego oprogramowania, następująca po 1.8 i 1.7, itd., Gdzie 1.7, 1.8 i 1.9 w jakiś sposób zazwyczaj dodają niewielkie ilości nowych funkcji obok poprawek błędów. Ponieważ jest to xx0.x, jest to pierwsza wersja 1.9 i pierwsza kompilacja tej wersji.

Dobre informacje można również znaleźć w artykule Wikipedii na ten temat .

Major.Minor.Bugs

(Lub jakąś odmianę tego)

Błędy to zwykle poprawki błędów bez nowej funkcjonalności.

Drobne to pewna zmiana, która dodaje nową funkcjonalność, ale nie zmienia programu w żaden istotny sposób.

Główna to zmiana w programie, która albo łamie starą funkcjonalność, albo jest tak duża, że ​​w jakiś sposób zmienia sposób, w jaki użytkownicy powinni korzystać z programu.

Każdy wybiera, co chce zrobić z tymi liczbami. Kusiło mnie, aby nazwać wydania abc, ponieważ i tak jest to raczej głupie. Biorąc to pod uwagę, to, co widziałem w ciągu ostatnich ponad 25 lat rozwoju, zwykle działa w ten sposób. Powiedzmy, że numer Twojej wersji to 1.2.3.

„1” oznacza „poważną” zmianę. Zwykle jest to pierwsze wydanie, duża zmiana zestawu funkcji lub przepisanie znaczących części kodu. Gdy zestaw funkcji jest określony i przynajmniej częściowo zaimplementowany, przechodzisz do następnego numeru.

„2” oznacza wydanie w ramach serii. Często używamy tej pozycji, aby pochwycić funkcje, które nie pojawiły się w ostatnim głównym wydaniu. Ta pozycja (2) prawie zawsze wskazuje na dodanie funkcji, zwykle z poprawkami błędów.

„3” w większości sklepów oznacza wydanie łatki / poprawki błędów. Prawie nigdy, przynajmniej od strony komercyjnej, nie wskazuje to na znaczący dodatek. Jeśli funkcje pojawiają się na pozycji 3, to prawdopodobnie dlatego, że ktoś sprawdził coś, zanim dowiedzieliśmy się, że musimy wprowadzić poprawki błędów.

Poza pozycją „3”? Nie mam pojęcia, dlaczego ludzie robią takie rzeczy, po prostu robi się to bardziej zagmatwane.

W szczególności niektóre OSS rzucają to wszystko z szału. Na przykład wersja 10 Traca to tak naprawdę 0.10.XX Myślę, że wielu ludziom w świecie OSS brakuje pewności siebie lub po prostu nie chcą ogłaszać, że mają ukończone główne wydanie.

W pliku C # AssemblyInfo.cs można zobaczyć następujące elementy:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision to moje przypuszczenie.
Ale może się znacznie różnić w zależności od produktu.

Major.minor.point.build zwykle. Major i minor są oczywiste, punkt to wydanie zawierające kilka drobnych poprawek błędów, a build to tylko identyfikator kompilacji.

Tak. Główne wydania dodają duże, nowe funkcje, mogą łamać kompatybilność lub mieć znacząco różne zależności itp.

Mniejsze wydania również dodają funkcje, ale są mniejsze, czasami okrojone wersje z wersji głównej beta.

Jeśli występuje składnik trzeciego numeru wersji, zwykle służy on do ważnych poprawek błędów i poprawek bezpieczeństwa. Jeśli jest ich więcej, to tak naprawdę zależy to tak bardzo od produktu, że trudno udzielić ogólnej odpowiedzi.

Wydaje mi się, że paradygmat poprawki major release.minor release.bug jest dość powszechny.

W niektórych umowach o wsparcie przedsiębiorstwa istnieje $$$ (lub naruszenie odpowiedzialności kontraktowej) związane ze sposobem wyznaczania konkretnego zwolnienia. Na przykład umowa może uprawniać klienta do pewnej liczby głównych wydań w danym okresie lub obiecywać, że będzie mniej niż x liczba mniejszych wersji w danym okresie lub że wsparcie będzie nadal dostępne dla tak wielu wydania. Oczywiście bez względu na to, ile słów zostanie umieszczonych w umowie, aby wyjaśnić, czym jest wersja główna w porównaniu z wersją drugorzędną, zawsze jest to subiektywne i zawsze będą istnieć szare obszary - prowadzące do możliwości, że dostawca oprogramowania może oszukać system pokonać takie postanowienia umowne.

Ludzie nie zawsze dostrzegają subtelną różnicę między numerami wersji, takimi jak 2.1, 2.0.1 lub 2.10 - zapytaj pracownika pomocy technicznej, ile razy mieli z tym problemy. Deweloperzy są zorientowani na szczegóły i znają struktury hierarchiczne, więc jest to dla nas martwe pole.

Jeśli to możliwe, pokaż klientom prostszy numer wersji.

W przypadku biblioteki numer wersji informuje o poziomie zgodności między dwoma wydaniami, a tym samym o tym, jak trudna będzie aktualizacja.

Wydanie poprawki błędów musi zachować zgodność plików binarnych, źródłowych i serializacji.

Mniejsze wydania oznaczają różne rzeczy dla różnych projektów, ale zwykle nie muszą zachowywać zgodności ze źródłami.

Główne numery wersji mogą złamać wszystkie trzy formy.

Więcej o przesłankach pisałem tutaj .

Kombinacja głównych, pomocniczych, poprawek, kompilacji, poprawek bezpieczeństwa itp.

Pierwsze dwa to główne i poboczne - reszta zależy od projektu, firmy, a czasem społeczności. W systemach operacyjnych, takich jak FreeBSD, będziesz mieć 1.9.0.1_number reprezentujący poprawkę bezpieczeństwa.

Zależy nieco od języka, na przykład Delphi i C # mają różne znaczenia.

Zwykle pierwsze dwie liczby reprezentują wersję główną i podrzędną, tj. 1.0 dla pierwszego prawdziwego wydania, 1.1 dla kilku ważnych poprawek błędów i pomniejszych nowych funkcji, 2.0 dla dużego nowego wydania funkcji.

Trzecia liczba może odnosić się do „naprawdę pomniejszej” wersji lub poprawki. 1.0.1 to na przykład bardzo mała poprawka do 1.0.0. Ale może również zawierać numer wersji z systemu kontroli źródła lub stale rosnącą liczbę, która rośnie z każdą kompilacją. Lub datownik.

Trochę więcej szczegółów tutaj . „oficjalnie” w .net cztery numery to „Major.Minor.Build.Rvision”, podczas gdy w Delphi są „Major.Minor.Release.Build”. Używam „Major.Minor.ReallyMinor.SubversionRev” do mojej wersji.

Zwykle liczby mają format version.major.minor.hotfix, a nie poszczególne składniki wewnętrzne. Tak więc wersja 1.9.0.1 byłaby wersją 1, wydaniem głównym 9 (z v1), wydaniem pomocniczym (z v1.9) 0, poprawką 1 z (v1.9.0).

Pierwsza liczba jest zwykle nazywana głównym numerem wersji. Zasadniczo jest używany do oznaczania znaczących zmian między kompilacjami (tj. Kiedy dodajesz wiele nowych funkcji, zwiększasz wersję główną). Komponenty z różnymi wersjami głównymi tego samego produktu prawdopodobnie nie są kompatybilne.

Następna liczba to pomocniczy numer wersji. Może reprezentować nowe funkcje lub szereg poprawek błędów lub małych zmian w architekturze. Komponenty tego samego produktu, które różnią się podrzędnym numerem wersji, mogą współpracować ze sobą lub nie i prawdopodobnie nie powinny.

Następny jest zwykle nazywany numerem kompilacji. Może to być zwiększane codziennie, przy każdej „wydanej” kompilacji lub w ogóle przy każdej kompilacji. Mogą występować niewielkie różnice między dwoma komponentami, które różnią się tylko numerem kompilacji i zazwyczaj dobrze ze sobą współpracują.

Ostateczna liczba to zwykle numer wersji. Często jest to używane w procesie kompilacji automatycznej lub podczas tworzenia jednorazowych kompilacji jednorazowych do testów.

Kiedy zwiększamy swoje numery wersji zależy od ciebie, ale powinny one zawsze przyrost lub pozostanie taka sama . Wszystkie komponenty mogą mieć ten sam numer wersji lub tylko zwiększać numer wersji zmienionych komponentów.

Numer wersji złożonego oprogramowania reprezentuje cały pakiet i jest niezależny od numerów wersji części. Gizmo w wersji 3.2.5 może zawierać Foo w wersji 1.2.0 i Bar w wersji 9.5.4.

Podczas tworzenia numerów wersji użyj ich w następujący sposób:

1. Pierwsza liczba to wydanie główne. Jeśli wprowadzisz znaczące zmiany w interfejsie użytkownika lub musisz przerwać istniejące interfejsy (tak, że Twoi użytkownicy będą musieli zmienić kod interfejsu), powinieneś przejść do nowej wersji głównej.

2. Druga liczba powinna wskazywać, że zostały dodane nowe funkcje lub coś działa inaczej wewnętrznie. (Na przykład baza danych Oracle może zdecydować o zastosowaniu innej strategii pobierania danych, przyspieszając większość rzeczy, a niektóre wolniej). Istniejące interfejsy powinny nadal działać, a interfejs użytkownika powinien być rozpoznawalny.

3. Dalsza numeracja wersji zależy od osoby piszącej oprogramowanie - Oracle używa pięciu (!) Grup, tj. wersja Oracle to coś w rodzaju 10.1.3.0.5. Począwszy od trzeciej grupy w dół, powinieneś wprowadzać tylko poprawki błędów lub drobne zmiany w funkcjonalności.

te, które różnią się mniej, to pierwsze dwa, dla major.minor, po czym może to być wszystko, od kompilacji, wersji, wydania, po dowolne niestandardowe algorytmy (jak w niektórych produktach MS)

Każda organizacja / grupa ma swój własny standard. Ważne jest, aby trzymać się dowolnej notacji, w przeciwnym razie Twoi klienci będą zdezorientowani. Powiedziawszy, że użyłem normalnie 3 liczb:

x.yz.bbbbb. Gdzie: x: to wersja główna (główne nowe funkcje) y: to numer wersji pomocniczej (małe nowe funkcje, drobne ulepszenia bez zmian interfejsu użytkownika) z: to dodatek Service Pack (w zasadzie taki sam jak xy, ale z kilkoma poprawkami błędów bbbb: to numer kompilacji, który jest naprawdę widoczny tylko w oknie „Informacje” wraz z innymi szczegółami dotyczącymi obsługi klienta. bbbb to darmowy format i każdy produkt może używać własnego.

Oto czego używamy:

1. Pierwsza liczba = ogólna era systemu. Zmienia się co kilka lat i zazwyczaj stanowi fundamentalną zmianę w technologii, funkcjach klienta lub obu.
2. Druga liczba = wersja schematu bazy danych. Zwiększenie tej liczby wymaga migracji bazy danych, a więc jest to znacząca zmiana (lub replikacja systemów, a zatem zmiana struktury bazy danych wymaga starannego procesu aktualizacji). Resetuje się do 0, jeśli zmieni się pierwsza liczba.
3. Trzecia liczba = zmiana tylko oprogramowania. Zwykle można to zaimplementować na kliencie po kliencie, ponieważ schemat bazy danych pozostaje niezmieniony. Resetuje się do zera, jeśli zmieni się druga liczba.
4. Numer wersji Subversion. Wypełniamy to automatycznie podczas kompilacji za pomocą narzędzia TortoiseSVN. Ta liczba nigdy się nie resetuje, ale stale rośnie. Korzystając z tego, zawsze możemy odtworzyć dowolną wersję.

Ten system dobrze nam służy, ponieważ każdy numer ma jasną i ważną funkcję. Widziałem inne zespoły zmagające się z pytaniem o liczbę większą / mniejszą (jak duża zmiana jest duża) i nie widzę korzyści z tego. Jeśli nie musisz śledzić zmian w bazie danych, po prostu przejdź do 3- lub 2-cyfrowego numeru wersji i ułatw sobie życie!

wersja: v1.9.0.1

gdzie-

. v jest skrótem od wersji. To zależy od firmy w zależności od nazewnictwa przyjętego w jego organizacji. Może milczeć w jakiejś organizacji, takiej jak 1.9.0.1

. 1 oznacza wersję główną, zostanie zaktualizowana Modyfikacja architektoniczna stosów aplikacji, infrastruktury (platformy) lub odsłoniętego interfejsu sieciowego

. 9 incates minor, zostanie zaktualizowany o takie działania, jak dodawanie nowych komponentów, takich jak interfejs użytkownika, api, baza danych itp; w ramach określonej architektury

. 0 oznacza funkcję, zostanie zaktualizowana o wszelkie ulepszenia istniejących komponentów (interfejs użytkownika, interfejs API, baza danych itp.)

. 1 wskazuje licznik kompilacji dla wszystkich faz głównych, pomocniczych i funkcji. Zawiera również poprawki poprodukcyjne.