Apa "konvensi penamaan versi" yang Anda gunakan? [Tutup]

Apakah konvensi penamaan versi yang berbeda cocok untuk proyek yang berbeda? Apa yang Anda gunakan dan mengapa?

Secara pribadi, saya lebih suka nomor build dalam heksadesimal (mis. 11BCF), ini harus ditambah secara teratur. Dan kemudian untuk pelanggan nomor versi 3 digit sederhana, yaitu 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Saya menemukan diri saya jarang setuju sepenuhnya dengan Jeff Atwood, tetapi saya cenderung mengikuti pendapatnya tentang .NET penomoran versi .

(Versi utama). (Versi kecil). (Nomor revisi). (Nomor pembuatan)

Lebih sering daripada tidak, untuk proyek pribadi, saya menemukan ini berlebihan. Beberapa kali di mana saya telah bekerja pada proyek-proyek besar seperti mesin pencari di C # Saya terjebak pada konvensi ini dan telah dapat menggunakannya sebagai pelacak internal secara efektif.

Versi Semantik ( http://semver.org/ ) pantas disebutkan di sini. Ini adalah spesifikasi publik untuk skema versi, dalam bentuk [Major].[Minor].[Patch]. Motivasi untuk skema ini adalah untuk mengkomunikasikan makna dengan nomor versi.

Saya tidak menggunakannya tetapi saya telah melihatnya dan ini adalah struktur yang menarik:

Year.Month.Day.Build

Cukup dijelaskan.

Saya mencoba menggunakan kebijakan Versi RubyGems Rasional di mana:

• Nomor versi utama bertambah ketika kompatibilitas biner rusak
• Nomor versi minor bertambah ketika fungsionalitas baru ditambahkan
• Perubahan nomor pembuatan untuk perbaikan bug.

Berikut adalah pendekatan yang sangat bagus untuk penomoran versi:

• N.x.K, di mana Ndan Kbilangan bulat. Contoh: 1.x.0, 5.x.1, 10.x.33. Digunakan untuk build menengah .
• N.M.K, di mana N, Mdan Kbilangan bulat. Contoh: 1.0.0, 5.3.1, 10.22.33. Digunakan untuk rilis .
• N.x.x, di mana Nbilangan bulat. Contoh: 1.x.x. Digunakan untuk cabang pendukung .
• N.M.x, di mana Ndan Mbilangan bulat. Contoh: 1.0.x. Digunakan untuk cabang rilis .

Berikut adalah gambar untuk ilustrasi sederhana dari pendekatan penomoran versi:

PAberarti pra-alfa A berarti alfa B berarti beta AR berarti alfa-rilis BR berarti beta-release RC berarti kandidat rilis ST berarti stabil

Keuntungan dari pendekatan penomoran versi tersebut adalah sebagai berikut:

• Ini mewakili spesifik siklus hidup pengembangan perangkat lunak tangkas .
• Ini memperhitungkan spesifik akun struktur repositori kode sumber .
• Ini menjelaskan diri bagi mereka yang terbiasa dengan pola. Setiap pola mewakili artefak yang berbeda. Pola seperti itu dapat dengan mudah diurai dan digunakan untuk tujuan lain, seperti pelacakan masalah.
• Pola pola versi, yang dasar untuk pendekatan versi yang dijelaskan dapat digunakan untuk mengumpulkan metrik dan perencanaan .
• Ini difokuskan pada konsep kematangan dan tingkat kualitas . Seringkali nomor versi seperti 1.0.0 ditugaskan tanpa banyak keperluan (ketika perangkat lunak berada di alpha yang dalam). Pendekatan penomoran versi yang disajikan memungkinkan untuk menetapkan beberapa tingkat kematangan. Dalam kasus paling sederhana, ia hanya memiliki dua level: build menengah ( N.x.K) dan release ( N.M.K). Rilis berarti perangkat lunak dengan nomor versi lengkap ( N.M.K) telah melalui semacam proses manajemen kualitas dalam perusahaan / organisasi / tim pemasok.
• Ini adalah bukti sifat lincah dari pengembangan dan pengujian.
• Mendorong pendekatan modular untuk struktur dan arsitektur perangkat lunak.

Ada juga diagram yang lebih kompleks yang menggambarkan pendekatan versi secara terperinci. Anda juga mungkin menemukan slide presentasi bermanfaat yang menjelaskan transisi ke pendekatan versi dan aplikasi SCMFViz yang menggambarkan prinsip-prinsip dasar pendekatan penomoran versi. Slide presentasi juga menjelaskan mengapa penting untuk tetap berpegang pada pendekatan versi yang sama sepanjang masa proyek perangkat lunak.

Secara pribadi, sikap saya terhadap penggunaan versi tanggal dan bukan nomor versi asli mengasumsikan bahwa pengembang perangkat lunak dengan versi tanggal:

• Tidak tahu apa-apa tentang siklus pengembangan perangkat lunak . Pengembangan biasanya gesit dan berulang. Pendekatan penomoran versi harus mewakili sifat berulang dari proses pengembangan perangkat lunak.
• Jangan pedulikan kualitas perangkat lunak . Kontrol kualitas dan jaminan gesit dan berulang. Sama seperti pengembangan. Dan nomor versi harus menjadi bukti sifat lincah dan berulang pengembangan dan kontrol kualitas / jaminan.
• Jangan pedulikan arsitektur atau ide aplikasi mereka. Nomor versi utama ( Ndalam N.M.K) bertanggung jawab untuk solusi arsitektur dan prinsip yang mendasari aplikasi. Nomor versi utama Nharus diubah sesuai dengan perubahan arsitektur atau perubahan ide-ide utama dan prinsip kerja / fungsinya.
• Tidak memiliki kendali atas basis kode mereka . Mungkin hanya ada satu cabang (trunk) dan digunakan untuk semuanya. Yang secara pribadi menurut saya tidak benar karena mendorong basis kode untuk menjadi satu tempat sampah besar.

Pendekatan ini mungkin tampak sedikit kontroversial, tetapi saya percaya ini adalah cara paling mudah untuk memberikan nomor versi perangkat lunak yang sesuai.

Untuk setiap versi utama yang Anda rilis, tidak jarang memiliki versi kerja yang Anda sebut internal. Misalnya, pada pekerjaan terakhir saya, kami merujuk ke versi utama dengan konvensi penamaan yang terinspirasi Ubuntu berikut:

[kondisi sakit-sakitan] [nama binatang aliteratif]

Yang memberi nama seperti " Limp Lamprey ", " Wounded Wombat " dan " Asthmatic Anteater ".

Pastikan kecuali itu nama yang benar-benar keren agar tidak bocor ke pelanggan Anda.

Generation.Version.Revision.Build (9.99.999.9999)

Generasi jarang berubah. Hanya menghidupkan produk: DOS -> Windows, rekayasa ulang lengkap.

Versi untuk perubahan besar yang tidak kompatibel, fungsionalitas baru, perubahan pada beberapa paradigma spesifik pada perangkat lunak, dll.

Revisi sering dilakukan (fitur kecil dan perbaikan bug).

Build adalah informasi internal.

git describememberikan ekstensi yang bagus untuk konvensi penomoran apa pun yang Anda pilih. Cukup mudah untuk menyematkan ini dalam proses pembuatan / pengemasan / penyebaran Anda.

Misalkan Anda memberi nama ABC versi rilis yang ditandai (major.minor.maintenance). git describepada komit yang diberikan akan menemukan leluhur yang diberi tag terbaru dari komit, kemudian tempel pada jumlah komit sejak saat itu, dan SHA1 disingkat dari komit:

1.2.3-164-g6f10c

Jika Anda benar-benar di salah satu versi, tentu saja, Anda hanya akan mendapatkan tag (1.2.3).

Ini memiliki manfaat yang bagus untuk memberi tahu Anda secara persis sumber apa yang Anda buat, sementara tidak harus setiap nomor membuat sendiri.

Major.Minor.Public (build) [alpha / beta / trial], seperti "4.08c (1290)"

• Dengan Major menjadi nomor versi utama (1, 2, 3 ...)
• Minor menjadi versi minor 2 digit (01, 02, 03 ...). Biasanya puluhan digit bertambah ketika fungsi baru yang signifikan ditambahkan, yang hanya untuk perbaikan bug.
• Publik menjadi rilis publik bangunan (a, b, c, d, e), yang sering berbeda dari versi minor jika versi minor tidak pernah dirilis sebagai pembaruan publik
• build, menjadi nomor build aktual yang dicatat oleh kompiler.
• dengan TRIAL, ALPHA, BETA X, atau RC X ditambahkan untuk kasus-kasus khusus.

Saya lebih suka nomor versi yang memberikan makna semantik. Selama Anda dapat menggunakan nomor versi untuk melacak bug yang dilaporkan dengan versi tertentu untuk perubahan yang terjadi pada kode sumber (dan dalam sistem manajemen aktivitas Anda) maka Anda mungkin menggunakan metode yang tepat.

Saya menggunakan NET. Jadi saya terjebak dengan sistem penomoran versi. NET tapi saya mencoba untuk memberikan makna semantik untuk angka-angka begitu

major.minor.build.revision

• major = (hingga proyek)
• minor = (hingga proyek)
• build = build number dari Hudson (Anda bisa menggunakan TeamCity atau TeamBuild, dll. di sini)
• revisi = subversi atau revisi bazaar (tergantung pada proyek dan apa penggunaannya)

Kami selalu memastikan bahwa nomor versi terlihat dengan cara tertentu (dengan program berbasis konsol batch kami yang dicetak ke konsol dan file log, dengan aplikasi web pada bilah menu di bagian atas biasanya)

Dengan cara ini jika klien melaporkan masalah, kami dapat menggunakan nomor versi untuk melacak jika mereka menggunakan versi terbaru dan berapa banyak masalah yang kami miliki dengan versi tertentu.

Ini semua tentang keterlacakan!

Kami menggunakan Major.Minor.Build # .YYMMDD [suffix], karena kami biasanya hanya melakukan satu build produksi pada hari tertentu (tetapi menggunakan ab / c / d akhiran jika ada lebih dari satu) dan YYMMDD memberikan pengguna / pelanggan / manajemen indikasi umur bangunan, di mana 6.3.1389 tidak.

Angka-angka utama bertambah dengan fitur produk yang signifikan (berbayar).

Angka minor bertambah dengan perbaikan / peningkatan (pembaruan gratis).

Bangun selalu meningkat; tidak semua membuat kapal, jadi itu bukan perkembangan linier.

Nomor versi harus memiliki informasi yang cukup sehingga Anda terhindar dari konflik dan memperbaiki bug dalam masalah tipe rilis yang salah, tetapi tidak boleh menyampaikan informasi tambahan yang tidak relevan.

Misalnya jika Anda menggunakan tanggal pelanggan dapat mengatakan bahwa mereka memiliki versi yang lebih lama, dan tambalan terhadap versi lama dapat memiliki versi yang membingungkan.

Saya pribadi suka versi semantik :

• Rilis adalah Major. Minor.Patch
• Patch peningkatan setiap kali Anda merilis bangunan.
• Minor kenaikan setiap kali fungsi yang kompatibel mundur ditambahkan.
• Major bertambah ketika fungsionalitas baru tidak kompatibel.
• Ketika Major== 0 Anda berada di alfa / pra-rilis. Major> = 1 adalah rilis publik Anda.
• Angka yang lebih rendah diatur ulang ke 0 setiap kali Anda menambah, jadi

  1.5.3-> 1.5.4(perbaikan bug) -> 1.6.0(fitur minor) -> 2.0.0(melanggar perubahan)

              1.0.0
                |
              1.0.1
                |
(publik 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (publik 1.1)
                |
(publik 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (publik 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zadalah nomor versi internal kami. X.Yadalah nomor versi publik, nomor yang memiliki arti bagi klien kami. Ketika sebuah X.Y.Zversi menjadi publik, tidak akan pernah ada X.Y.(Z+1)versi: versi publik selalu yang terakhir dari seri.

X bertambah ketika versi utama dirilis.

Y digunakan untuk cabang pemeliharaan dari rilis utama tersebut, hanya untuk perbaikan bug.

Zdigunakan secara internal, dan tidak memiliki arti tetap. Sampai sekarang, saya membuat Zversi baru ketika saya berpikir bahwa aplikasi tersebut memiliki serangkaian fitur yang menarik untuk ditunjukkan kepada non pengembang, dan relatif stabil. Dengan cara ini, saya dapat menunjukkan demo dari "versi bagus yang terakhir diketahui" dari aplikasi ketika seseorang bertanya. Dalam waktu dekat, saya berencana untuk menggunakan Zversi nomor untuk memberi nama "target" fitur, di bugtracker kami.

Sebagai catatan tambahan, kami menggunakan maven (dengan releaseperintah) untuk menambah nomor versi. Jadi, ada X.Y.Z-SNAPSHOTversi juga (yang menunjukkan versi antara X.Y.(Z-1)dan X.Y.Z).