Apakah ada konvensi penamaan standar untuk tag git? [Tutup]

Saya telah melihat banyak proyek menggunakan v1.2.3sebagai konvensi penamaan untuk tag di git. Saya juga melihat beberapa kegunaan 1.2.3. Apakah ada gaya yang disahkan secara resmi, atau adakah argumen yang bagus untuk menggunakan keduanya?

Versi 1.0.0 dari Semantic Versioning , oleh Tom Preston-Werner dari ketenaran GitHub, memiliki sub-spesifikasi yang membahas hal ini:

Spesifikasi Penandaan (SemVerTag)

Sub-spesifikasi ini HARUS digunakan jika Anda menggunakan sistem kontrol versi (Git, Mercurial, SVN, dll) untuk menyimpan kode Anda. Menggunakan sistem ini memungkinkan alat otomatis untuk memeriksa paket Anda dan menentukan kepatuhan SemVer dan versi yang dirilis.

1. Saat menandai rilis di sistem kontrol versi, tag untuk versi HARUS "vX.YZ" mis. "V3.1.0" .

Namun, setelah diskusi ini dihapus, dan tidak lagi hadir dalam versi terbaru dari spesifikasi SemVer (2.0.0 pada saat penulisan). Sebuah utas diskusi selanjutnya di tempat yang sama masuk ke kedalaman yang lebih dalam, dan menghasilkan Is "v1.2.3" yang baru versi semantik? sedang ditambahkan ke FAQ di mastercabang SemVer , meskipun pada saat penulisan (lebih dari 2 tahun kemudian) perubahan ini masih belum ada dalam spesifikasi yang dirilis secara resmi.

Tampaknya ada dua konvensi yang mendominasi (dengan asumsi Anda juga mematuhi standar yang masuk akal untuk menentukan nomor rilisnya sendiri):

• v1.2.3
• 1.2.3

Keuntungannya v1.2.3adalah bahwa dokumentasi Git (dan juga dokumentasi Mercurial) menggunakan format itu dalam contoh-contohnya, dan bahwa beberapa "otoritas" seperti kernel Linux dan Git sendiri menggunakannya. ( Versi Semantic yang disebutkan itu digunakan untuk menggunakannya tetapi tidak lagi.)

Keuntungannya 1.2.3adalah bahwa gitweb atau GitHub dapat secara otomatis menawarkan unduhan tarball atau zip dari formulir packagename-$tag.tar.gz(dan saya pikir cukup mapan bahwa tarball tidak boleh disebutkan namanya package-v1.2.3.tar.gz). Atau, Anda dapat menggunakan git describesecara langsung untuk menghasilkan nomor versi tarball. Untuk proyek ringan tanpa proses rilis formal, kemungkinan ini bisa sangat nyaman. Juga harus dicatat bahwa Versi Semantic sama sekali bukan satu-satunya atau standar yang diterima secara universal untuk penomoran versi. Dan proyek-proyek penting seperti GNOME serta banyak proyek lain menggunakan 1.2.3penamaan tag.

Saya pikir mungkin sudah terlambat untuk mengkonsolidasikan posisi ini. Seperti biasa, konsisten dan masuk akal.

Pembaruan: Seperti yang disebutkan dalam komentar ini , GitHub sekarang menawarkan nama tarball dengan 'v' dilucuti dari tag.

Alasan untuk 'v' sebelumnya adalah historis. SCCS yang lebih lama (cvs, rcs) tidak dapat membedakan antara pengidentifikasi tag dan nomor revisi. Pengidentifikasi tag dibatasi untuk tidak memulai dengan nilai numerik sehingga angka revisi dapat dideteksi.

Tidak yang saya tahu.
Tetapi Git tidak akan mengizinkan tag dan cabang dengan nama yang sama secara bersamaan, jadi jika Anda memiliki cabang " 1.1" untuk 1.1karya, jangan beri tag " 1.1", gunakan misalnya " v1.1"

Saran manajer paket baru untuk menandai versi tanpa awalan v(seperti komposer untuk proyek PHP). SemVer 2.0 tidak memiliki spesifikasi tag. Ini dilakukan dengan sengaja karena menghindari konflik. Namun disarankan untuk menambahkan awalan vdalam dokumentasi dan referensi teks. Sebagai contoh format v1.0.4bukan full version 1.0.4atau ver. 1.0.4cukup verbose dan elegan dalam dokumentasi.

Kami menggunakan cabang dan tag untuk pekerjaan spesifik rilis yang diikuti oleh rilis aktual, masing-masing:

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

Setiap pengembang membuat keputusan mental tentang apakah pekerjaan yang akan mereka lakukan berlaku hanya untuk menguasai atau jika itu juga relevan dengan cabang. Anda bisa melihat bahwa perubahan yang dibuat untuk cabang digabungkan kembali pada master, tetapi beberapa perubahan pada master tidak akan pernah berjalan di cabang (yaitu, yang tidak dimaksudkan untuk rilis 1.6, dalam contoh ini).

Ketika kami siap untuk merilis, kami memberi tag dan kemudian menggabungkan kembali untuk yang terakhir kalinya, dan kami memberi nama tag dengan nama yang sama dengan cabang, tetapi dengan pengidentifikasi tambahan tentang versi apa itu, misalnya "1.6-release" atau "1.6-beta" atau "1.6-rc2", dan lain-lain.

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

Saya tidak tahu standar apa pun. Saya cukup memilih nama tag saya sehingga saya dapat menempel

VERSION = `git describe --tags`

di skrip build saya. Jadi, konvensi penamaan tag sebenarnya tergantung pada konvensi penamaan versi proyek.

Tidak ada satu praktik terbaik yang saya sadari. Berikut ini beberapa tautan:

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

Secara umum, versi ( 0.0.1,, v0.2.1...) mungkin bergandengan tangan dengan beberapa pelacakan masalah dapat dianggap sebagai pendekatan yang masuk akal. (.. walaupun saya biasanya menggunakan vnama tag -prefixed .. lihat juga @VonC jawaban)