Jakiej „konwencji nazewnictwa wersji” używasz? [Zamknięte]

Czy różne konwencje nazewnictwa wersji są odpowiednie dla różnych projektów? Czego używasz i dlaczego?

Osobiście wolę numer kompilacji w systemie szesnastkowym (np. 11BCF), należy go bardzo regularnie zwiększać. A następnie dla klientów prosty 3-cyfrowy numer wersji, tj. 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Rzadko się zgadzam z Jeffem Atwoodem, ale zwykle podążam za jego opinią na temat konwencji numeracji wersji .NET .

(Wersja główna). (Wersja mniejsza). (Numer wersji). (Numer kompilacji)

Najczęściej w przypadku projektów osobistych uważam, że to przesada. Kilka razy, kiedy pracowałem nad znaczącymi projektami, takimi jak wyszukiwarki w C #, trzymałem się tej konwencji i mogłem skutecznie używać jej jako wewnętrznego modułu śledzącego.

Na uwagę zasługuje tutaj wersja semantyczna ( http://semver.org/ ). Jest to publiczna specyfikacja schematu kontroli wersji w formie [Major].[Minor].[Patch]. Motywacją tego schematu jest przekazanie znaczenia za pomocą numeru wersji.

Nie używam go, ale widziałem i jest to ciekawa struktura:

Year.Month.Day.Build

Wyjaśniłem.

Próbuję użyć zasady RubyGems Rational Versioning, w której:

• Główny numer wersji jest zwiększany, gdy binarna zgodność jest uszkodzona
• Podrzędny numer wersji jest zwiększany, gdy dodawana jest nowa funkcjonalność
• Zmienia się numer kompilacji poprawek błędów.

Oto bardzo szczegółowe podejście do numeracji wersji:

• N.x.K, gdzie Ni Ksą liczbami całkowitymi. Przykłady: 1.x.0, 5.x.1, 10.x.33. Używany do kompilacji pośrednich .
• N.M.K, Gdzie N, Mi Ksą liczbami całkowitymi. Przykłady: 1.0.0, 5.3.1, 10.22.33. Używany do wydań .
• N.x.x, gdzie Njest liczbą całkowitą. Przykład: 1.x.x. Używany do oddziałów wsparcia .
• N.M.x, gdzie Ni Msą liczbami całkowitymi. Przykład: 1.0.x. Używany do gałęzi wydania .

Oto zdjęcie przedstawiające proste podejście do numeracji wersji:

PAoznacza pre-alfa A oznacza alfa B oznacza beta AR oznacza uwalnianie alfa BR oznacza uwalnianie beta RC oznacza kandydat do uwolnienia ST oznacza stabilny

Zalety takiego numerowania wersji są następujące:

• Reprezentuje specyfikę zwinnego cyklu rozwoju oprogramowania .
• Uwzględnia specyfikę struktury repozytorium kodu źródłowego .
• Jest to oczywiste dla tych, którzy przyzwyczaili się do wzorców. Każdy wzór reprezentuje inny artefakt. Takie wzorce można łatwo przeanalizować i wykorzystać do innych celów, takich jak śledzenie problemów.
• Zestaw wzorców wersjonowania, które są podstawowe dla opisanego podejścia do wersjonowania, można wykorzystać do gromadzenia metryk i planowania .
• Koncentruje się na koncepcjach dojrzałości i poziomie jakości . Bardzo często takie numery wersji jak 1.0.0 są przypisywane bez dużej potrzeby (gdy oprogramowanie jest w głębokiej alfie). Prezentowane podejście do numeracji wersji pozwala ustalić kilka poziomów dojrzałości. W najprostszym przypadku będzie miał tylko dwa poziomy: budowanie pośrednie ( N.x.K) i release ( N.M.K). Wydanie oznacza, że ​​oprogramowanie z pełnym numerem wersji ( N.M.K) przeszło jakiś proces zarządzania jakością w firmie / organizacji / zespole dostawcy.
• Jest to dowód na zwinny charakter zarówno rozwoju, jak i testowania.
• Zachęca do modułowego podejścia do struktury i architektury oprogramowania.

Istnieje również bardziej złożony schemat przedstawiający podejście do wersjonowania w szczegółach. Możesz także znaleźć przydatne slajdy prezentacji opisujące przejście do podejścia do kontroli wersji i aplikacji SCMFViz ilustrujące podstawowe zasady podejścia do numeracji wersji. Slajdy prezentacji wyjaśniają również, dlaczego ważne jest stosowanie tego samego podejścia do wersji przez cały czas trwania projektu oprogramowania.

Osobiście moje podejście do używania wersji daty zamiast prawdziwych numerów wersji zakłada, że ​​twórcy oprogramowania z wersjami datowanymi:

• Nic nie wiesz o cyklu życia oprogramowania . Rozwój jest zwykle zwinny i iteracyjny. Metoda numeracji wersji powinna odzwierciedlać iteracyjny charakter procesu tworzenia oprogramowania.
• Nie dbaj o jakość oprogramowania . Kontrola jakości i zapewnienie są sprawne i powtarzalne. Podobnie jak rozwój. Numer wersji powinien być dowodem zwinności i iteracji zarówno rozwoju, jak i kontroli / zapewnienia jakości.
• Nie przejmuj się architekturą ani ideą ich zastosowania. Główny numer wersji ( Nin N.M.K) odpowiada zarówno za rozwiązanie architektoniczne, jak i za zasadę aplikacji. Numer wersji głównej Nnależy zmienić odpowiednio do zmian w architekturze lub zmian głównych pomysłów i zasad jego działania / funkcjonowania.
• Nie kontroluj ich bazy kodu . Prawdopodobnie jest tylko jedna gałąź (pień) i jest używana do wszystkiego. Co osobiście nie uważam za słuszne, ponieważ zachęca bazę kodów, aby stała się jednym dużym wysypiskiem śmieci.

Takie podejście może wydawać się nieco kontrowersyjne, ale uważam, że jest to najprostszy sposób nadania oprogramowaniu odpowiednich numerów wersji.

W przypadku każdej ważniejszej wersji, którą wydajesz, nierzadko zdarza się, aby działająca wersja nazywała ją wewnętrznie. Na przykład w mojej ostatniej pracy mówiliśmy o głównej wersji z następującą konwencją nazewnictwa inspirowaną Ubuntu:

[stan chorobowy] [nazwa zwierzęcia aliteracyjnego]

Które dały takie nazwy jak „ Limp Lamprey ”, „ Wounded Wombat ” i „ Asthmatic Anteater ”.

Upewnij się, że jeśli nie jest to naprawdę fajna nazwa, nie wycieknie ona do Twoich klientów.

Generation.Version.Revision.Build (9.99.999.9999)

Generacja rzadko się zmienia. Tylko duży włącz produkt: DOS -> Windows, kompletne przeprojektowanie.

Wersja jest przeznaczona na duże niekompatybilne zmiany, nową funkcjonalność, zmiany niektórych określonych paradygmatów w oprogramowaniu itp.

Korekta jest często wykonywana (drobne funkcje i naprawa błędów).

Kompilacja to informacje wewnętrzne.

git describestanowi ładne rozszerzenie dowolnej konwencji numeracji, którą wybrałeś. Łatwo jest osadzić to w procesie kompilacji / pakowania / wdrażania.

Załóżmy, że nazywasz swoje oznaczone wersje wersje ABC (major.minor.maintenance). git describena danym zatwierdzeniu znajdzie najnowszego otagowanego przodka zatwierdzenia, następnie wskaż liczbę zatwierdzeń od tego czasu i skrót SHA1 zatwierdzenia:

1.2.3-164-g6f10c

Jeśli faktycznie jesteś w jednej z wersji, oczywiście otrzymasz tylko tag (1.2.3).

Ma to tę zaletę, że pozwala dokładnie wiedzieć , z jakiego źródła zbudowałeś, bez konieczności samodzielnego liczenia każdej kompilacji.

Major.Minor.Public (build) [alfa / beta / trial], taki jak „4.08c (1290)”

• Major to główny numer wersji (1, 2, 3 ...)
• Drobne, będące 2-cyfrową wersją podrzędną (01, 02, 03 ...). Zazwyczaj cyfra dziesiątek jest zwiększana, gdy dodawana jest znacząca nowa funkcjonalność, tylko dla poprawek błędów.
• Publiczny będący publicznym wydaniem kompilacji (a, b, c, d, e), który często różni się od wersji dodatkowej, jeśli wersja dodatkowa nigdy nie jest wydawana jako aktualizacja publiczna
• build, będący faktycznym numerem kompilacji, który kompilator śledzi.
• z TRIAL, ALPHA, BETA X lub RC X dołączonymi do tych specjalnych przypadków.

Wolę numery wersji, które przypisują jakieś znaczenie semantyczne. Tak długo, jak można użyć numeru wersji do śledzenia błędów zgłaszanych w konkretnej wersji zmian, które nastąpiły w kodzie źródłowym (i systemie zarządzania aktywnością), prawdopodobnie używasz właściwej metody.

Używam .NET, więc utknąłem z systemem numeracji wersji .NET, ale staram się nadać semantyczne znaczenie liczbom, więc

major.minor.build.revision

• major = (do projektu)
• minor = (do projektu)
• build = numer kompilacji z Hudson (możesz użyć TeamCity lub TeamBuild itp. tutaj)
• rewizja = rewizja subversion lub bazar (w zależności od projektu i jego zastosowania)

Zawsze upewniamy się, że numer wersji jest w jakiś sposób widoczny (w naszych programach opartych na konsoli wsadowej jest drukowany na konsoli i plik dziennika, z aplikacjami internetowymi zwykle na pasku menu u góry)

W ten sposób, jeśli klienci zgłaszają problemy, możemy użyć numeru wersji do śledzenia, czy używają najnowszej wersji i ile problemów mieliśmy z poszczególnymi wersjami.

Chodzi o identyfikowalność!

Używamy Major.Minor.Build # .YYMMDD [sufiks], ponieważ zwykle wykonujemy tylko jedną wersję produkcyjną w danym dniu (ale używamy sufiksu ab / c / d, jeśli jest więcej niż jeden), a YYMMDD daje użytkownikom / klientom / zarządzanie wskazanie wieku kompilacji, gdzie 6.3.1389 nie.

Znaczne liczby rosną wraz ze znaczącymi funkcjami produktu (odpłatnymi).

Drobne liczby rosną wraz z poprawkami / ulepszeniami (bezpłatna aktualizacja).

Kompilacja zawsze wzrasta; nie wszystkie budują statek, więc nie jest to postęp liniowy.

Numery wersji powinny zawierać wystarczającą ilość informacji, aby uniknąć konfliktów i usunięcia błędu w niewłaściwym typie wydania, ale nie powinny przekazywać dodatkowych informacji, które nie są istotne.

Na przykład, jeśli użyjesz daty, klienci mogą stwierdzić, że mają starszą wersję, a poprawki do starych wersji mogą mieć mylące wersje.

Osobiście lubię wersję semantyczną :

• Wydania są Major. Minor.Patch
• Patch zwiększa się za każdym razem, gdy wypuszczasz wersję.
• Minor zwiększa się za każdym razem, gdy dodawane są funkcje kompatybilne wstecz.
• Major zwiększa, gdy nowa funkcja nie jest kompatybilna wstecz.
• Gdy Major== 0 jesteś w fazie alfa / przedpremierowej. Major> = 1 to twoje publiczne wydania.
• Niższe liczby resetują się do 0 za każdym razem, gdy zwiększasz, więc

  1.5.3-> 1.5.4(poprawka błędu) -> 1.6.0(drobna funkcja) -> 2.0.0(zerwanie zmiany)

              1.0.0
                |
              1.0.1
                |
(publiczny 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (publiczny 1.1)
                |
(publiczny 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (publiczny 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zto nasz wewnętrzny numer wersji. X.Yto publiczny numer wersji, który ma znaczenie dla naszych klientów. Gdy X.Y.Zwersja stanie się publiczna, nigdy nie będzie X.Y.(Z+1)wersji: wersja publiczna jest zawsze ostatnią serią.

X jest zwiększany, gdy zostaje wydana główna wersja.

Y jest używany do gałęzi serwisowych tych głównych wydań, tylko do naprawiania błędów.

Zjest używany wewnętrznie i nie ma stałego znaczenia. Do tej pory tworzę nową Zwersję, gdy myślę, że aplikacja ma zestaw funkcji, które są interesujące do pokazania dla programistów i jest stosunkowo stabilna. W ten sposób mogę pokazać demo „ostatniej znanej dobrej wersji” aplikacji, gdy ktoś o to poprosi. W niedalekiej przyszłości planuję użyć Zwersji numerycznych do nazwania „celu” funkcji w naszym narzędziu do wykrywania błędów.

Na marginesie, używamy maven (z releasepoleceniem), aby zwiększyć numer wersji. Istnieją więc również X.Y.Z-SNAPSHOTwersje (co oznacza dowolną wersję między X.Y.(Z-1)i X.Y.Z).