Existe uma convenção de nomenclatura padrão para tags git? [fechadas]

Eu já vi muitos projetos usando v1.2.3como convenção de nomenclatura para tags no git. Eu também vi algum uso 1.2.3. Existe um estilo oficialmente aprovado, ou existem bons argumentos para usá-lo?

A versão 1.0.0 do Semantic Versioning , de Tom Preston-Werner, do GitHub, tinha uma subespecificação que abordava isso:

Especificação de marcação (SemVerTag)

Esta sub-especificação DEVE ser usada se você usar um sistema de controle de versão (Git, Mercurial, SVN, etc) para armazenar seu código. O uso desse sistema permite que ferramentas automatizadas inspecionem seu pacote e determinem a conformidade do SemVer e as versões lançadas.

1. Ao marcar lançamentos em um sistema de controle de versão, o tag para uma versão DEVE ser "vX.YZ", por exemplo, "v3.1.0" .

No entanto, após a discussão, isso foi removido e não está mais presente na versão mais recente da especificação SemVer (2.0.0 no momento da redação). Um tópico de discussão posterior no mesmo local foi aprofundado e resultou em uma nova versão "v1.2.3" é uma semântica? sendo adicionado ao FAQ na masterfilial do SemVer , embora no momento da redação (mais de 2 anos depois) essa alteração ainda não esteja presente nas especificações oficialmente lançadas.

Parece haver duas convenções dominantes (supondo que você também cumpra algum padrão razoável para numerar os lançamentos):

• v1.2.3
• 1.2.3

As vantagens v1.2.3são que a documentação do Git (e também a documentação do Mercurial) usa esse formato em seus exemplos, e que várias "autoridades", como o kernel do Linux e o próprio Git , o utilizam. (O mencionado Semantic Versioning costumava usá-lo, mas não usa mais.)

As vantagens 1.2.3são que o gitweb ou o GitHub pode oferecer automaticamente um download de tarball ou zip do formulário packagename-$tag.tar.gz(e acho que está bem estabelecido que um tarball não deve ser nomeado package-v1.2.3.tar.gz). Como alternativa, você pode usar git describediretamente para gerar números de versão do tarball. Para projetos leves, sem um processo formal de liberação, essas possibilidades podem ser bastante convenientes. Deve-se notar também que o controle de versão semântico não é de forma alguma o único ou um padrão universalmente aceito para numeração de versões. E projetos notáveis ​​como o GNOME, bem como inúmeros outros projetos, usam a 1.2.3nomeação de tags.

Acho que provavelmente é tarde demais para consolidar essas posições. Como sempre, seja consistente e faça sentido.

Atualização: Conforme mencionado neste comentário, o GitHub agora oferece um nome tarball com o 'v' retirado da tag.

O motivo do 'v' anterior é histórico. O SCCS mais antigo (cvs, rcs) não conseguiu distinguir entre um identificador de marca e um número de revisão. Os identificadores de tag foram restringidos para não começar com um valor numérico, para que os números de revisão pudessem ser detectados.

Não que eu saiba.
Mas o Git não permitirá uma tag e uma ramificação com o mesmo nome ao mesmo tempo; portanto, se você tiver uma ramificação " 1.1" para 1.1trabalhos, não coloque uma tag " 1.1", use por exemplo " v1.1"

Novos conselhos dos gerentes de pacotes para marcar versões sem prefixo v(como o compositor para projetos PHP). O SemVer 2.0 não tem nada a ver com especificação de tags. É feito intencionalmente devido a evitar conflitos. No entanto, é recomendável adicionar prefixo vna documentação e nas referências de texto. Como formato de exemplo, em v1.0.4vez de completo version 1.0.4ou ver. 1.0.4é bastante detalhado e elegante na documentação.

Usamos ramificações e tags para o trabalho específico da versão, seguido pela versão real, respectivamente:

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

Todo desenvolvedor toma uma decisão mental sobre se o trabalho que está prestes a comprometer é aplicável apenas para dominar ou se também é relevante para o ramo. Você pode ver que as alterações feitas na ramificação são mescladas novamente no master, mas algumas alterações no master nunca serão executadas no branch (ou seja, aquelas que não se destinam à liberação 1.6, neste exemplo).

Quando estamos prontos para o lançamento, marcamos a etiqueta e, em seguida, retornamos uma última vez, e nomeamos a tag com o mesmo nome que o ramo, mas com um identificador extra sobre qual versão específica é, por exemplo, "versão 1.6" ou "1.6-beta" ou "1.6-rc2", etc.

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

Não conheço nenhum padrão. Simplesmente escolho os nomes das minhas tags para poder

VERSION = `git describe --tags`

nos meus scripts de construção. Portanto, a convenção de nomenclatura das tags realmente depende da convenção de nomenclatura da versão do projeto.

Não existe uma melhor prática que eu estou ciente de. Aqui estão alguns links:

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

Geralmente, controle de versão ( 0.0.1, v0.2.1...), talvez de mãos dadas com algum problema de rastreamento pode ser considerada uma abordagem plausível. (.. embora eu costumo usar vnomes de tags predefinidos. veja também a resposta @VonC)