Esiste una convenzione di denominazione standard per i tag git? [chiuso]

Ho visto molti progetti usare v1.2.3come convenzione di denominazione per i tag in git. Ho anche visto un certo uso 1.2.3. Esiste uno stile ufficialmente approvato o ci sono buoni argomenti per usarli?

La versione 1.0.0 di Semantic Versioning , di Tom Preston-Werner di fama GitHub, aveva una sotto-specifica per questo:

Specifiche di tagging (SemVerTag)

Questa sotto-specifica DOVREBBE essere utilizzata se si utilizza un sistema di controllo della versione (Git, Mercurial, SVN, ecc.) Per memorizzare il codice. L'utilizzo di questo sistema consente agli strumenti automatizzati di ispezionare il pacchetto e determinare la conformità di SemVer e le versioni rilasciate.

1. Quando si codificano le versioni in un sistema di controllo versione, il tag per una versione DEVE essere "vX.YZ", ad esempio "v3.1.0" .

Tuttavia, dopo la discussione, questo è stato rimosso e non è più presente nell'ultima versione delle specifiche SemVer (2.0.0 al momento della stesura). Un successivo thread di discussione nello stesso posto è andato più in profondità e ha portato a un nuovo "v1.2.3" è una versione semantica? viene aggiunto alla FAQ in di SemVer masterramo, anche se al momento della scrittura (oltre 2 anni più tardi) questo cambiamento è non è ancora presente nelle specifiche ufficialmente rilasciato.

Sembrano esserci due convenzioni dominanti (supponendo che si rispettino anche alcuni standard ragionevoli per la numerazione delle versioni stesse):

• v1.2.3
• 1.2.3

I vantaggi v1.2.3sono che la documentazione di Git (e anche la documentazione di Mercurial) usa quel formato nei suoi esempi e che diverse "autorità" come il kernel Linux e Git stesso lo usano. (Il menzionato Semantic Versioning lo usava ma non lo fa più.)

I vantaggi 1.2.3sono che gitweb o GitHub possono automaticamente offrire un download tarball o zip del modulo packagename-$tag.tar.gz(e penso che sia abbastanza stabilito che un tarball non debba essere nominato package-v1.2.3.tar.gz). In alternativa, è possibile utilizzare git describedirettamente per generare numeri di versione tarball. Per i progetti leggeri senza un processo di rilascio formale, queste possibilità possono essere abbastanza convenienti. Va anche notato che la versione semantica non è affatto l'unico o uno standard universalmente accettato per la numerazione delle versioni. Notevoli progetti come GNOME e innumerevoli altri progetti usano la 1.2.3denominazione dei tag.

Penso che sia probabilmente troppo tardi per consolidare queste posizioni. Come sempre, sii coerente e ha senso.

Aggiornamento: Come menzionato in questo commento, GitHub ora offre un nome tarball con la 'v' rimossa dal tag.

La ragione della precedente "v" è storica. SCCS precedenti (cvs, rcs) non è stato in grado di distinguere tra un identificatore di tag e un numero di revisione. Gli identificatori di tag sono stati limitati per non iniziare con un valore numerico in modo da poter rilevare i numeri di revisione.

Non che io sappia.
Ma Git non consentirà contemporaneamente un tag e un ramo con lo stesso nome, quindi se hai un ramo " 1.1" per 1.1opere, non mettere un tag " 1.1", usa ad esempio " v1.1"

I nuovi gestori di pacchetti consigliano di taggare le versioni senza prefisso v(come il compositore per progetti PHP). SemVer 2.0 non ha nulla a che vedere con le specifiche dei tag. È fatto intenzionalmente per evitare conflitti. Tuttavia, si consiglia di aggiungere un prefisso vnella documentazione e nei riferimenti testuali. Ad esempio, il formato v1.0.4anziché pieno version 1.0.4o ver. 1.0.4è abbastanza dettagliato ed elegante nella documentazione.

Usiamo rami e tag per il lavoro specifico del rilascio seguito rispettivamente dal rilascio effettivo:

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

Ogni sviluppatore prende una decisione mentale sul fatto che il lavoro che sta per commettere sia applicabile solo al master o se sia rilevante anche per la filiale. È possibile notare che le modifiche apportate al ramo vengono ricollegate al master, ma alcune modifiche al master non andranno mai sul ramo (vale a dire quelle non destinate alla versione 1.6, in questo esempio).

Quando siamo pronti per il rilascio, lo etichettiamo e poi lo ricolleghiamo un'ultima volta, e chiamiamo il tag con lo stesso nome del ramo, ma con un identificatore aggiuntivo su quale particolare versione sia, ad esempio "1.6-release" o "1.6-beta" o "1.6-rc2", eccetera.

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

Non conosco standard. Scelgo semplicemente i nomi dei miei tag in modo tale da poter attaccare a

VERSION = `git describe --tags`

nei miei script di build. Pertanto, la convenzione di denominazione dei tag dipende in realtà dalla convenzione di denominazione della versione del progetto.

Non esiste una best practice di cui io sia a conoscenza. Ecco alcuni link:

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

In generale, il controllo delle versioni ( 0.0.1, v0.2.1, ...) forse di pari passo con qualche problema-tracking potrebbe essere considerato un approccio plausibile. (.. anche se di solito uso vnomi di tag prefissati .. vedi anche risposta @VonC)