Czy istnieje standardowa konwencja nazewnictwa dla tagów git? [Zamknięte]

Widziałem wiele projektów używających v1.2.3jako konwencji nazewnictwa tagów w git. Widziałem też jakiś użytek 1.2.3. Czy istnieje styl oficjalnie zatwierdzony lub czy istnieją jakieś dobre argumenty przemawiające za jego użyciem?

Wersja 1.0.0 Semantic Versioning autorstwa Toma Prestona-Wernera ze sławy GitHub zawierała specyfikację podrzędną dotyczącą tego problemu:

Specyfikacja tagowania (SemVerTag)

Tej pod-specyfikacji POWINNY być używane, jeśli używasz systemu kontroli wersji (Git, Mercurial, SVN itp.) Do przechowywania kodu. Korzystanie z tego systemu pozwala zautomatyzowanym narzędziom sprawdzać pakiet i określać zgodność SemVer i wydane wersje.

1. Podczas oznaczania wydań w systemie kontroli wersji znacznikiem wersji MUSI być „vX.YZ”, np. „V3.1.0” .

Jednak po dyskusji zostało to usunięte i nie jest już obecne w najnowszej wersji specyfikacji SemVer (2.0.0 w momencie pisania). Późniejszy wątek dyskusji w tym samym miejscu pogłębił się i zaowocował nową Czy „v1.2.3” jest wersją semantyczną? jest dodany do FAQ w SemVer za masteroddział, chociaż w chwili pisania tego tekstu (ponad 2 lata później), zmiana ta jest nadal nieobecny w oficjalnie wydany spec.

Wydaje się, że istnieją dwie dominujące konwencje (zakładając, że przestrzegasz również rozsądnego standardu numerowania samych wydań):

• v1.2.3
• 1.2.3

Zaletą tego v1.2.3jest to, że dokumentacja Git (a także dokumentacja Mercurial) używa tego formatu w swoich przykładach i że korzysta z niego kilka „autorytetów”, takich jak jądro Linuksa i sam Git . (Wspomniana wersja semantyczna korzystała z niej, ale już jej nie ma.)

Zaletą tego 1.2.3jest to, że gitweb lub GitHub mogą automatycznie oferować tarball lub zip do pobrania formularza packagename-$tag.tar.gz(i myślę, że ustalono, że tarball nie powinien mieć nazwy package-v1.2.3.tar.gz). Alternatywnie możesz użyć git describebezpośrednio do wygenerowania numerów wersji tarball. W przypadku lekkich projektów bez formalnego procesu wydania te możliwości mogą być dość wygodne. Należy również zauważyć, że wersja semantyczna w żadnym wypadku nie jest jedynym lub powszechnie akceptowanym standardem numeracji wersji. I znaczące projekty, takie jak GNOME, a także niezliczone inne projekty używają 1.2.3nazw znaczników.

Myślę, że prawdopodobnie jest już za późno na konsolidację tych pozycji. Jak zawsze bądź konsekwentny i rozsądny.

Aktualizacja: Jak wspomniano w tym komentarzu, GitHub oferuje teraz nazwę tarball z „v” pozbawionym tagu.

Powód poprzedzającego „v” jest historyczny. Starsze SCCS (cvs, rcs) nie mogły odróżnić identyfikatora znacznika od numeru wersji. Identyfikatory znaczników zostały ograniczone, aby nie zaczynały się od wartości liczbowej, aby można było wykryć numery wersji.

Nie żebym o tym wiedział.
Ale Git nie zezwoli na tag i gałąź o tej samej nazwie w tym samym czasie, więc jeśli masz gałąź „ 1.1” dla 1.1prac, nie umieszczaj tagu „ 1.1”, użyj na przykład „ v1.1”

Nowe porady menedżerów pakietów do oznaczania wersji bez prefiksu v(jak kompozytor dla projektów PHP) SemVer 2.0 nie ma nic na temat specyfikacji znaczników. Odbywa się to celowo ze względu na unikanie konfliktów. Jednak to zaleca się , aby dodać przedrostek vw odnośnikach dokumentacji i tekstowych. Jako przykładowy format v1.0.4zamiast pełnego version 1.0.4lub ver. 1.0.4jest wystarczająco szczegółowy i elegancki w dokumentacji.

Używamy rozgałęzień i tagów do pracy specyficznej dla wydania, a następnie odpowiednio:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Każdy programista podejmuje decyzję, czy praca, którą zamierzają wykonać, ma zastosowanie tylko do opanowania, czy też dotyczy branży. Widać, że zmiany dokonane w gałęzi są scalane z powrotem w systemie głównym, ale niektóre zmiany w systemie głównym nigdy nie zostaną wprowadzone w gałęzi (w tym przykładzie nie są przeznaczone dla wersji 1.6).

Kiedy jesteśmy gotowi do wydania, tagujemy go, a następnie scalamy po raz ostatni, i nazywamy tag o tej samej nazwie co gałąź, ale z dodatkowym identyfikatorem o konkretnej wersji, np. „1.6-release” lub „1.6-beta” lub „1.6-rc2” i tak dalej.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

Nie znam żadnych standardów. Po prostu wybieram nazwy tagów, aby móc je przykleić

VERSION = `git describe --tags`

w moich skryptach kompilacji. Konwencja nazewnictwa tagów faktycznie zależy od konwencji nazewnictwa wersji projektu.

Nie ma jednej najlepszej praktyki, o której wiem. Oto kilka linków:

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging

Generalnie wersjonowania ( 0.0.1, v0.2.1...) może towarzyszyć jakiś problem śledzenia można uznać za wiarygodne podejście. (.. chociaż zwykle używam v-prefiksowanych nazw znaczników .. patrz także odpowiedź @VonC)