Git etiketleri için standart bir adlandırma kuralı var mı? [kapalı]

v1.2.3Git'teki etiketler için adlandırma kuralı olarak kullanılan birçok proje gördüm . Biraz fayda gördüm 1.2.3. Resmi olarak onaylanmış bir stil var mı, ya da bunları kullanmak için iyi bir argüman var mı?

Semantic Versioning'in 1.0.0 sürümü , GitHub şöhretinden Tom Preston-Werner tarafından, aşağıdakileri ele alan bir alt spesifikasyona sahipti :

Etiketleme Spesifikasyonu (SemVerTag)

Kodunuzu saklamak için bir sürüm kontrol sistemi (Git, Mercurial, SVN, vb.) Kullanıyorsanız bu alt şartname KULLANILMALIDIR. Bu sistemi kullanmak, otomatik araçların paketinizi denetlemesine ve SemVer uyumluluğunu ve yayınlanan sürümlerini belirlemesine olanak tanır.

1. Bir sürüm kontrol sistemindeki sürümleri etiketlerken, sürümün etiketi "vX.YZ" olmalıdır, örn. "V3.1.0" .

Ancak, tartışmadan sonra bu kaldırıldı ve artık SemVer spesifikasyonunun en son sürümünde (yazma sırasında 2.0.0) mevcut değil. Aynı yerde daha sonraki bir tartışma konusu daha derinlere gitti ve yeni bir "v1.2.3" anlamsal bir sürüm mü? varlık eklendi SemVer en SSS için masteryazma anda (üzerinde 2 yıl sonra) bu değişiklik olmasına rağmen, şube hala mevcut değil resmen piyasaya spec.

İki baskın kural var gibi görünüyor (bültenleri kendileri numaralandırmak için makul bir standarda uyduğunuz varsayılarak):

• v1.2.3
• 1.2.3

Avantajları v1.2.3Git belgelerinin (ve ayrıca Mercurial belgelerinin) örneklerinde bu biçimi kullanması ve Linux çekirdeği ve Git'in kendisi gibi birçok "otoritenin" kullanmasıdır. (Bahsedilen Semantik Sürüm , onu kullanıyordu ancak artık kullanmıyordu.)

Avantajları 1.2.3olduğu gitweb ya GitHub otomatik bir tarball teklif veya formun zip indir olabilir packagename-$tag.tar.gz(ve oldukça tarball gerektiğini kurulan düşünüyorum değil adlandırılabilir package-v1.2.3.tar.gz). Alternatif olarak, git describetarball sürüm numaraları oluşturmak için doğrudan kullanabilirsiniz . Resmi bir serbest bırakma süreci olmayan hafif projeler için bu olasılıklar oldukça uygun olabilir. Anlamsal Sürüm Oluşturmanın, sürüm numaralandırması için hiçbir şekilde tek veya evrensel olarak kabul edilmiş bir standart olmadığı da unutulmamalıdır. GNOME gibi kayda değer projeler ve sayısız diğer proje 1.2.3etiket adlandırma yöntemini kullanmaktadır .

Sanırım bu pozisyonları pekiştirmek için çok geç. Her zaman olduğu gibi tutarlı olun ve mantıklı olun.

Güncelleme: As belirtilen bu yorumun, GitHub şimdi etiketin sıyrılıp 'v' ile tarball adını sunmaktadır.

Önceki 'v'nin nedeni tarihseldir. Eski SCCS (cvs, rcs) bir etiket tanımlayıcı ve bir düzeltme numarası arasında ayrım yapamadı. Etiket tanımlayıcılarının, revizyon numaralarının algılanabilmesi için sayısal bir değerle başlamaması kısıtlanmıştır.

Bildiğim kadarıyla hayır.
Ancak Git, aynı ada sahip bir etikete ve bir şubeye aynı anda izin vermez; bu nedenle 1.1, 1.1işler için bir " " şubeniz varsa , " 1.1" etiketi koymayın , örneğin " v1.1" kullanın

Etiket versiyonlarına Yeni paket yöneticileri danışma olmadan öneki v(gibi besteci PHP projeleri için). SemVer 2.0'da etiket spesifikasyonu hakkında hiçbir şey yoktur. Çatışmalardan kaçınmak nedeniyle kasıtlı olarak yapılır. Ancak , dokümantasyon ve metin referanslarına önek eklemeniz önerilirv . Örnek biçim v1.0.4olarak dolu yerine version 1.0.4veya ver. 1.0.4yeterli ayrıntılı ve belgelerde zarif.

Serbest bırakmaya özgü çalışma için sırasıyla dallar ve etiketler kullanıyoruz.

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

Her geliştirici taahhüt etmek üzere oldukları işin sadece ustalar için mi yoksa branşla da ilgili olup olmadığı konusunda zihinsel bir karar verir. Şube üzerinde yapılan değişikliklerin master'da yeniden birleştirildiğini görebilirsiniz, ancak master'daki bazı değişiklikler hiçbir zaman şubeye gitmez (yani, bu örnekte 1.6 sürümü için tasarlanmamış olanlar).

Serbest bırakmaya hazır olduğumuzda, onu etiketliyoruz ve son bir kez geri birleştiriyoruz ve etiketi şube ile aynı adla adlandırıyoruz, ancak belirli bir sürüm hakkında ekstra bir tanımlayıcıyla, örneğin "1.6 sürümü" olarak adlandırıyoruz. veya "1.6-beta" veya "1.6-rc2", vb.

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

Hiçbir standart bilmiyorum. Etiket isimlerimi seçebilirim ki

VERSION = `git describe --tags`

yapı komut dosyalarında. Dolayısıyla, etiket adlandırma kuralı aslında projenin sürüm adlandırma kuralına bağlıdır.

Orada hiçbir kimse ben farkındayım en iyi uygulama. İşte bazı bağlantılar:

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

Genel olarak, sürüm oluşturma ( 0.0.1,, v0.2.1...) belki bazı sorun izleme ile el ele makul bir yaklaşım olarak kabul edilebilir. (.. genellikle v-prefixed etiket adlarını kullanmama rağmen .. ayrıca @VonC yanıtına bakın)