Gibt es eine Standard-Namenskonvention für Git-Tags? [geschlossen]

Ich habe viele Projekte gesehen, die v1.2.3als Namenskonvention für Tags in git verwendet wurden. Ich habe auch eine Verwendung gesehen 1.2.3. Gibt es einen offiziell anerkannten Stil oder gibt es gute Argumente dafür?

Version 1.0.0 von Semantic Versioning von Tom Preston-Werner von GitHub Fame hatte eine Unterspezifikation, die sich mit diesem Thema befasste:

Tagging-Spezifikation (SemVerTag)

Diese Unterspezifikation SOLLTE verwendet werden, wenn Sie ein Versionskontrollsystem (Git, Mercurial, SVN usw.) zum Speichern Ihres Codes verwenden. Mit diesem System können automatisierte Tools Ihr Paket überprüfen und die SemVer-Konformität sowie die freigegebenen Versionen ermitteln.

1. Beim Markieren von Releases in einem Versionskontrollsystem MUSS das Tag für eine Version "vX.YZ" sein, z . B. "v3.1.0" .

Nach der Diskussion wurde dies jedoch entfernt und ist in der neuesten Version der SemVer-Spezifikation (2.0.0 zum Zeitpunkt des Schreibens) nicht mehr vorhanden . Ein späterer Diskussionsthread an derselben Stelle ging tiefer und führte zu einer neuen Ist "v1.2.3" eine semantische Version? wird zu den FAQ in der SemVer- Filiale hinzugefügtmaster , obwohl diese Änderung zum Zeitpunkt des Schreibens (über 2 Jahre später) in der offiziell veröffentlichten Spezifikation noch nicht vorhanden ist.

Es scheint zwei dominierende Konventionen zu geben (vorausgesetzt, Sie halten sich auch an einen vernünftigen Standard für die Nummerierung der Veröffentlichungen selbst):

• v1.2.3
• 1.2.3

Die Vorteile von v1.2.3sind, dass die Git-Dokumentation (und auch die Mercurial-Dokumentation) dieses Format in ihren Beispielen verwendet und dass mehrere "Autoritäten" wie der Linux-Kernel und Git selbst es verwenden. (Die erwähnte semantische Versionierung verwendete sie früher, aber nicht mehr.)

Die Vorteile von 1.2.3sind, dass gitweb oder GitHub automatisch einen Tarball- oder Zip-Download des Formulars anbieten können packagename-$tag.tar.gz(und ich denke, es ist ziemlich erwiesen , dass ein Tarball nicht benannt werden sollte package-v1.2.3.tar.gz). Alternativ können Sie git describedirekt Tarball-Versionsnummern generieren. Für leichte Projekte ohne formellen Freigabeprozess können diese Möglichkeiten sehr praktisch sein. Es sollte auch beachtet werden, dass die semantische Versionierung keineswegs der einzige oder allgemein akzeptierte Standard für die Versionsnummerierung ist. Bemerkenswerte Projekte wie GNOME sowie unzählige andere Projekte verwenden die 1.2.3Tag-Benennung.

Ich denke, es ist wahrscheinlich zu spät, um diese Positionen zu festigen. Seien Sie wie immer konsequent und sinnvoll.

Update: Wie in diesem Kommentar erwähnt, bietet GitHub jetzt einen Tarball-Namen an, bei dem das 'v' vom Tag entfernt ist.

Der Grund für das vorhergehende 'v' ist historisch. Ältere SCCS (cvs, rcs) konnten nicht zwischen einer Tag-ID und einer Revisionsnummer unterscheiden. Tag-IDs durften nicht mit einem numerischen Wert beginnen, damit Revisionsnummern erkannt werden konnten.

Nicht, dass ich davon Wüste.
Git lässt jedoch nicht zu, dass ein Tag und ein Zweig mit demselben Namen gleichzeitig verwendet werden. Wenn Sie also einen Zweig " 1.1" für 1.1Werke haben, setzen Sie kein Tag " 1.1", verwenden Sie beispielsweise " v1.1".

Neue Paketmanager empfehlen, Versionen ohne Präfix zu kennzeichnen v(wie Composer für PHP-Projekte). SemVer 2.0 hat nichts mit der Tag-Spezifikation zu tun. Dies geschieht absichtlich, um Konflikte zu vermeiden. Es wird jedoch empfohlen , Präfixe vin Dokumentationen und Textreferenzen hinzuzufügen . Als Beispielformat v1.0.4statt voll version 1.0.4oder ver. 1.0.4ausreichend ausführlich und elegant in der Dokumentation.

Wir verwenden Zweige und Tags für die Release-spezifische Arbeit, gefolgt von der eigentlichen Version:

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

Jeder Entwickler trifft eine mentale Entscheidung darüber, ob die Arbeit, die er begehen möchte, nur für den Master gilt oder ob sie auch für die Branche relevant ist. Sie können sehen, dass Änderungen, die am Zweig vorgenommen wurden, wieder auf dem Master zusammengeführt werden, aber einige Änderungen am Master werden niemals auf dem Zweig übernommen (dh diejenigen, die in diesem Beispiel nicht für die Version 1.6 vorgesehen sind).

Wenn wir zur Veröffentlichung bereit sind, markieren wir es und führen es ein letztes Mal wieder zusammen. Wir benennen das Tag mit demselben Namen wie der Zweig, aber mit einer zusätzlichen Kennung für die jeweilige Version, z. B. "1.6-Release". oder "1,6-beta" oder "1,6-rc2" usw.

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

Ich kenne keine Standards. Ich wähle einfach meine Tag-Namen so, dass ich ein kleben kann

VERSION = `git describe --tags`

in meinen Build-Skripten. Die Tag-Namenskonvention hängt also tatsächlich von der Versionsnamenkonvention des Projekts ab.

Es gibt keine eine beste Praxis , die ich bewusst bin. Hier sind einige Links:

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

Im Allgemeinen Versionsverwaltung ( 0.0.1, v0.2.1, ...) vielleicht Hand in Hand mit einigem Problem-Tracking eines plausibler Ansatz in Betracht gezogen werden könnte. (.. obwohl ich normalerweise v-präfixierte Tag-Namen verwende .. siehe auch @VonC Antwort)