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

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

• v1.2.3
• 1.2.3

Zaletą v1.2.3 jest to, że dokumentacja Git (a także dokumentacja Mercurial) używa tego formatu w swoich przykładach, a kilka "autorytetów", takich jak jądro Linuksa i Git używa tego samego formatu. (Wspomniane wersjonowanie semantyczne kiedyś go używałem, ale już nie.)

Zaletą 1.2.3 jest to, że gitweb lub GitHub mogą automatycznie oferować tarball lub zip do pobrania formularza packagename-$tag.tar.gz (i myślę, że jest całkiem ustalone, że tarball powinien , a nie być nazwany package-v1.2.3.tar.gz). Alternatywnie, możesz użyć git describe bezpośrednio do wygenerowania numerów wersji tarballa. W przypadku lekkich projektów bez formalnego procesu wydawania, możliwości te mogą być całkiem wygodne. Należy również zauważyć, że wersjonowanie semantyczne jest przez nie oznacza jedynego lub powszechnie akceptowanego standardu numeracji wersji. Znaczące projekty, takie jak GNOME, jak również niezliczone inne projekty, używają nazw znaczników 1.2.3.

Update: jak wspomniano w Ten komentarz, GitHub oferuje teraz nazwę tarballa z " v " usuniętym z tagu.

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

Nic mi o tym nie wiadomo.
Ale Git nie zezwala na tag i gałąź o tej samej nazwie w tym samym czasie, więc jeśli masz gałąź "1.1 " dla 1.1 działa, nie umieszczaj znacznika "1.1", użyj na przykład "v1.1"

Nowe Menedżery pakietów doradzają wersje znaczników bez prefiksu v (jak composer dla projektów PHP). SemVer 2.0 nie ma nic o specyfikacji znaczników. Robi się to celowo, unikając konfliktów. Jednak zaleca się dodanie prefiksu v w dokumentacji i odniesieniach tekstowych. Jako przykładowy format {[2] } zamiast pełnego version 1.0.4 lub ver. 1.0.4 jest wystarczająco wyrazisty i elegancki w dokumentacji.

Używamy gałęzi i tagów do pracy specyficznej dla Wydania, a następnie rzeczywistego wydania, odpowiednio:

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

Każdy programista podejmuje mentalną decyzję o tym, czy praca, którą zamierza wykonać, ma zastosowanie tylko do mastera, czy też jest istotna dla gałęzi. Widać, że zmiany wprowadzone w gałęzi są scalane z powrotem na master, ale niektóre zmiany na master nigdy nie wejdą do gałęzi (czyli te, które nie są przeznaczone dla wydania 1.6, w tym przykładzie).

Kiedy jesteśmy gotowi do wydania, oznaczamy go, a następnie łączymy z powrotem po raz ostatni, i nadajemy tag o tej samej nazwie co branch, ale z dodatkowym identyfikatorem o konkretnej wersji, np. "1.6-release "lub" 1.6-beta "lub" 1.6-RC2", itd.

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

Nie znam żadnych standardów. Po prostu wybieram moje nazwy tagów tak, że mogę przykleić

VERSION = `git describe --tags`

W moich skryptach budowania. Tak więc konwencja nazewnictwa tagów w rzeczywistości zależy od konwencji nazewnictwa wersji projektu.

Nie znam żadnej najlepszej praktyki. 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

Ogólnie rzecz biorąc, wersjonowanie (0.0.1, v0.2.1, ...) być może w parze z pewnym śledzeniem problemów można uznać za wiarygodne podejście. (.. chociaż zwykle używam v-prefiksowych nazw znaczników .. Zobacz też @ VonC odpowiedz)