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

107

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.
rjstelling
źródło

Odpowiedzi:

45

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.

Mike B.
źródło
1
Zwykle podąża za wzorem, który z powodzeniem stosowałem w wielu projektach, dużych i małych. To jest bardzo skuteczne.
luis.espinal
1
Jak / powinna się odnosić „numer kompilacji” do „identyfikatora zestawu zmian (skrótu)”? Czy jest to część skrótu, przyrostowa czy coś innego?
Jace Browning,
@Jace, gdzie pracuję, używamy Mercurial i wyłączamy numer zestawu zmian. Zawsze wypychamy / pobieramy tylko z jednego repozytorium, więc liczba nie jest unikalna dla konkretnego kasy. Mamy odpowiednio [major]. [Minor]. [Changeset] odpowiednio (chociaż liczby główne i drobne są często bardziej marketingowe niż wskazują postęp od ostatniej wersji).
Wai Ha Lee
Jeśli wywołasz ToString () w strukturze wersji .NET, kompilacja będzie trzecim numerem, a nie wersją. Jak widać w tym skrypcie PowerShell:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
Joel McBeth
Czy „numer kompilacji” oznacza, że ​​to tylko drobne poprawki, takie jak poprawki błędów? Czy jakakolwiek nowa funkcjonalność powinna mieć przynajmniej własny numer wersji?
Kyle Delaney,
90

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.

M. Dudley
źródło
Zaskoczony, że to nie jest więcej miłości.
Mark Canlas,
Spóźniłem się trochę na przyjęcie ... Dodałem tę odpowiedź 9 miesięcy po pierwotnym pytaniu. ;-)
M. Dudley,
Wygląda na to, że działa to tak samo, jak polityka RubyGems Rational Versioning, o której wspomniałem poniżej, tylko lepiej sformalizowana.
Ken Bloom
@MarkCanlas nie zyskuje więcej miłości, ponieważ łączy konkretne pomysły z tym, co stanowi wydanie główne / drobne / łatka. Mówi o API, co jest trochę ... dziwne
Rudolf Olah,
5
SemVer jest przeznaczony do tworzenia interfejsów API do wersjonowania, a nie do oprogramowania dla użytkownika: „Oprogramowanie korzystające z Semantic Versioning MUSI zadeklarować publiczny interfejs API”. Tak więc technicznie nie można używać SemVer bez publicznego API. Jednak sensowne może być zastosowanie czegoś podobnego do SemVer do wersjonowania aplikacji przeznaczonych dla użytkowników.
Ajedi32,
33

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

Year.Month.Day.Build

Wyjaśniłem.

Maniero
źródło
4
I zawsze wiesz, jak świeży jest twój kod ...! :)
Lipis
3
jest to również podobne do numerów wersji Ubuntu. Robią rok. Przykłady: 10.04 i 10.10
Brad Cupit
5
Warto wspomnieć, że działa to dobrze tylko dla systemu, który albo nie ma problemów ze zgodnością (strona internetowa), albo z natury rzeczy zawsze ma niezgodność (wydanie ubuntu).
jkerian
1
@jkerian, dlaczego zgodność ma dla tego znaczenie?
AviD
12
@AviD: Jestem trochę zdezorientowany, dlaczego o to pytasz, ponieważ prawie każda inna odpowiedź na to pytanie pokazuje systemy wersji zawierające informacje o zgodności. Twój wybór zależy od tego, jakie informacje chcesz nagrać z numerami wersji. Dla moich celów data nie ma w zasadzie żadnego znaczenia (rozpoczęcie od wersji 1 i zwiększenie każdej wersji byłoby poprawą). Czy kiedykolwiek rozgałęziałeś się? czy kiedykolwiek wydajecie „nową łatkę na starym kodzie”, wydając jednocześnie „nową wersję”? Ale w przypadku czegoś takiego jak strona internetowa lub system operacyjny system oparty na dacie wydaje się całkiem odpowiedni.
jkerian
13

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.
Ken Bloom
źródło
2
Jest to zasadniczo znane jako Semantic Versioning: semver.org
Patrice M.,
2
@PatriceM. Dziękujemy za udostępnienie tego linku. semver.org nie istniało, kiedy napisałem tę odpowiedź.
Ken Bloom
10

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:

Zwinna numeracja 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.

altern
źródło
Pierwszy link w dół ...............
Pacerier
8

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.

Jesse C. Slicer
źródło
2
Wygląda na nieefektywne wykorzystanie czasu i energii .............
Pacerier
10
Zostawiłem ten komentarz, ale to cię nie powstrzymało.
Jesse C. Slicer
To o całą wielkość mniej ......
Pacerier
7

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.

Maniero
źródło
Dobry pomysł. Skąd wziął się pomysł „generacji”?
Pacerier
6

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.

Cascabel
źródło
2

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.
Grandmaster B.
źródło
2

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ść!

Jeffrey Cameron
źródło
1

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.

JBRWilkinson
źródło
1

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)

W ten sposób, jeśli ktoś używa, powiedzmy, wersji, 1.5.3którą mógłby na pierwszy rzut oka powiedzieć, że może dokonać aktualizacji, aby 1.5.4uzyskać łatki, 1.6.0to dodałoby funkcjonalność i do której nie powinien się aktualizować 2.0.0(przynajmniej bez obsługi zmiany).

Keith
źródło
Semver działa tylko w przypadku interfejsów API. Nie produkty.
Pacerier
@Pacerier mógłbyś wyjaśnić dlaczego?
Keith,
@Pacerier, co nie oznacza, że ​​nie można użyć tego wzorca do numerowania wersji.
Keith
0
              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).

Barjak
źródło