Kapan Anda mengubah nomor versi utama / minor / tambalan Anda?


40

Kemungkinan Duplikat:
“Konvensi penamaan versi” apa yang Anda gunakan?

Apakah Anda mengubah nomor versi utama / minor / patch Anda tepat sebelum Anda rilis atau setelahnya?

Contoh: Anda baru saja merilis 1.0.0 ke dunia (huzzah!). Tapi tunggu, jangan terlalu banyak merayakannya. 1.1.0 akan keluar dalam enam minggu! Jadi, Anda memperbaiki bug dan melakukan pembangunan baru. Disebut apa bangunan itu? 1.1.0.0 atau 1.0.0.xxxy (di mana xxxy adalah jumlah build dari 1.0.0 yang ditingkatkan)?

Ingatlah bahwa Anda mungkin memiliki 100 fitur dan bug untuk masuk ke 1.1.0. Jadi mungkin lebih baik untuk menyebutnya 1.0.0.xxxy, karena Anda tidak jauh dari 1.1.0. Tetapi di sisi lain, pengembang lain mungkin bekerja pada 2.0.0, dalam hal ini build Anda mungkin lebih baik dinamai 1.1.0.0 dan 2.0.0.0-nya masing-masing daripada 1.0.0.xxxy dan 1.0.0.xxxz.


3
Saya tidak bertanya apakah Anda menggunakan major.minor.release.build atau skema lainnya. Saya bertanya pada titik apa dalam siklus rilis Anda mengubah nomor menjadi 3.2.0? Saat pertama kali memulai pengkodean 3.2.0 atau saat Anda merilis 3.2.0?
dave4351

Saya membuka kembali pertanyaan karena itu bukan pertanyaan "bagaimana" tetapi sebagai pertanyaan "kapan". Ini masih sangat mirip dengan duplikat yang ditandai sebelumnya namun dan dapat ditutup kembali.
maple_shaft

Jawaban:


24

Setelah Anda merilis perangkat lunak Anda, nomor versi harus segera ditambahkan.

Mengapa?

Mari kita asumsikan Anda mengikuti skema seperti Semantic Versioning , dan Anda memiliki nomor build dalam versi tersebut. Jadi Anda mungkin memiliki [Major]. [Minor]. [Patch]. [Build]. Saya akan memanggil bagian [Utama]. [Kecil]. [Patch] versi.

Anda akan membuat beberapa build selama pengembangan. Setiap build adalah snapshot pengembangan dari rilis Anda berikutnya. Masuk akal untuk menggunakan versi yang sama untuk pengembangan dan rilis build Anda. Versi menunjukkan apa yang melepaskan Anda bekerja menuju .

Jika Anda bersiap untuk rilis dan perangkat lunak melewati semua pengujiannya, Anda tidak ingin membangun kembali dan menguji ulang perangkat lunak hanya karena Anda harus memperbarui versi. Ketika Anda akhirnya membuat rilis, Anda menyatakan bahwa "build 1.1.0.23" untuk selanjutnya akan disebut sebagai "versi 1.1.0".

Model increment-after-release masuk akal untuk bercabang juga. Misalkan Anda memiliki cabang pengembangan arus utama, dan Anda membuat cabang pemeliharaan untuk rilis. Saat Anda membuat cabang rilis, cabang pengembangan Anda tidak lagi ditautkan ke nomor versi rilis itu. Cabang pengembangan berisi kode yang merupakan bagian dari rilis berikutnya, jadi versi tersebut harus mencerminkan hal itu.


6

Saya biasanya mencoba menggunakan SemVer untuk nomor versi internal. Sangat menyenangkan bisa mengetahui sesuatu tentang rilis berdasarkan semantik nomor versinya.

Selama pengembangan, saya mencoba untuk langsung mengubah nomor versi (jika mungkin) . Terkadang sulit untuk mengetahui apakah perubahan itu akan menjadi perubahan yang melanggar atau tidak (yang akan mempengaruhi nomor versi saya), jadi tidak ada yang "diatur dalam batu".

Untuk membahas contoh spesifik Anda:

  • Selama pengembangan, versi pra-rilis adalah 1.0.1-alpha.1, 1.0.1-alpha.2, dll.
  • Rilis terakhir perbaikan bug adalah versi 1.0.1.

Karena itu, nomor versi produk yang 'menghadap publik' sering kali ditentukan oleh pemasaran, dan sama sekali berbeda. Ini di luar kendali saya, jadi tidak ada gunanya mengkhawatirkannya.


4

Mari kita asumsikan ABCD dalam jawabannya. Kapan Anda menambah masing-masing komponen?

Pada dasarnya ditentukan oleh kebijakan perusahaan Anda. Kebijakan perusahaan kami adalah:

  • A - Perubahan signifikan atau tambahan (> 25%) dalam fungsi atau antarmuka.
  • B - perubahan kecil atau penambahan fungsi atau antarmuka.
  • C - perubahan kecil yang merusak antarmuka.
  • D - perbaikan untuk membangun yang tidak mengubah antarmuka.

4
Ya, tetapi dave4351 bertanya kapan (secara kronologis) Anda benar-benar mengedit nilai-nilai ini dalam kontrol sumber? Anda tidak mengubah nomor versi setiap kali Anda memasukkan kode, bukan?
M. Dudley

Seperti yang Anda lihat hanya D adalah kandidat yang akan diubah secara otomatis pada setiap build.
EL Yusubov

3

Dalam proyek / organisasi yang lebih besar, nomor versi utama dan kecil dikendalikan oleh departemen pemasaran dan biasanya bertambah karena alasan pemasaran. Di organisasi saya, kelompok bertujuan untuk merilis satu rilis utama dan satu rilis kecil setiap tahun. Harapannya adalah bahwa rilis utama mengandung fungsionalitas baru yang signifikan dan ada kompatibilitas biner antara API untuk semua rilis dengan nomor versi utama yang sama. Namun, pemasaran dapat memilih untuk menurunkan versi perubahan mayor ke minor karena fitur yang dijanjikan tidak dikirimkan atau sebaliknya terlihat melompati kompetisi katak, misalnya.

Angka bangunan utama dan kecil (c dan d dalam abcd) biasanya dikontrol oleh pengembangan. c adalah nomor build dan d digunakan untuk tambalan pada rilis atau versi c tertentu.

Dalam kasus Anda, ketika Anda mengubah nomor versi utama dan minor kurang relevan daripada memastikan angka bangunan utama dan kecil akurat. Di organisasi saya, kami mengubah angka bangunan utama dan kecil sebagai bagian dari proses percabangan dalam kontrol sumber. Cabang utama biasanya berisi versi terbaru tetapi pemasaran mungkin belum memutuskan nomor versi apa yang akan dirilis.


2

Kami mencoba dan mengikuti contoh Eclipse . Itu melakukan pekerjaan yang lebih baik untuk menjelaskan daripada yang saya bisa, tetapi efektif bagi kami itu bekerja seperti ini:

Ketika Anda merilis 1.0.0.0 nomor versi yang Anda ubah bergantung pada jenis perubahan yang Anda buat.

  • Rilis yang tidak mempengaruhi API, pertimbangkan perbaikan bug di belakang layar yang membuat API saat ini bekerja dengan cara yang diharapkan, dirilis pada 1.0.1
  • Rilis yang menambah API tetapi tidak mengubah API yang ada, Anda mungkin telah menambahkan fitur baru yang tidak membuat klien saat ini tak tertandingi dengan versi baru. Ini dapat mencakup sejumlah perbaikan di atas juga.
  • Rilis merusak API saat ini, menghapus sesuatu, mengubah sesuatu dengan cara yang mematahkan komparabilitas dengan klien saat ini. Ini dapat memiliki banyak perbaikan di atas juga.

Adapun cara menggunakan bagian ke-4 di nomor versi kami menggunakan ini untuk membedakan build yang berbeda di Nuget (solusi manajemen paket yang kami gunakan untuk .net). Ini memungkinkan kita untuk menghindari keharusan menghapus cache setiap kali kita perlu memperbarui perangkat lunak kita yang belum dirilis.


Saya secara khusus bertanya tentang build antar versi. Setelah rilis 1.0.0 GA, apakah bangunan Anda berikutnya, yang bekerja menuju 1.1.0, memiliki nomor versi yang tampak seperti 1.0.0.2592 atau 1.1.0.0?
dave4351

Mungkin cara lain untuk bertanya adalah: apakah rilis 1.0.0 Anda memiliki nomor build 1.0.0.0 (perubahan pada akhir siklus) atau 1.0.0.2591 (perubahan pada awal siklus)?
dave4351

-1 Tidak menjawab pertanyaan kapan akan menambah versi. Dokumen Eclipse hanya berbicara tentang semantik nomor versi.
M. Dudley

1

Tidak ada bangunan selanjutnya. Di cabang itu.

Versi ideal dari skema kami.

Identifikasi versi pada cabang mana pun adalah PRETTY_BRANCH_NAME-build dan PRETTY_BRANCH_NAME diperbaiki pada pembuatan cabang.

Skema percabangan kami (*) adalah sebagai berikut:

Cabang tingkat atas, PRETTY_BRANCH_NAME masing-masing adalah nama kode, berbicara tentang nomor versi di tingkat itu tidak ada artinya, mungkin ada skema yang direncanakan tetapi akan berubah sebelum rilis.

  • cabang TNG ( generasi berikutnya ) di mana pengembangan jangka panjang dilakukan. Seringkali kita bahkan tidak memilikinya dan tidak pernah (melepaskan) sub cabang.

  • cabang TCG ( generasi sekarang ) tempat pengembangan saat ini dilakukan. PRETTY_BRANCH_NAME adalah nama kode.

  • cabang TPG ( generasi sebelumnya ). Seringkali tidak ada lagi pengembangan yang dibuat di sini, tetapi mungkin ada aktivitas di cabang-cabang.

Subbranch dibuat dari cabang tingkat atas (TCG, di hadapan migrasi lambat TPG) ketika beta untuk rilis rilis utama dimulai. PRETTY_BRANCH_NAME adalah sesuatu seperti "1.3.X" (X adalah huruf, bukan digit, artinya kami bermaksud mengirimkan 1,3 rilis dari sini), umpan balik dari beta dimasukkan ke akun di sini sementara pekerjaan untuk rilis besar berikutnya dilakukan pada cabang TCG.

Idealnya, rilis harus snapshot pada cabang itu, tetapi kami tahu kami tidak sempurna dan sering perlu melakukan perubahan menit terakhir sambil memungkinkan orang lain untuk terus bekerja untuk rilis minor berikutnya. Jadi, sub-cabang dibuat untuk stabilisasi akhir dengan nama-nama cantik menjadi nomor versi resmi (pada saat itu bahkan pemasaran tidak ingin mengubahnya) seperti "1.3", "1.3.1" dari cabang "1.3.X", build terakhir pada masing-masing adalah rilis.

Jika kita memiliki tingkat keempat, nama-nama sub-cabang akan menjadi "1.3.0.X" yang darinya kita akan memiliki sub ^ 3 cabang "1.3.0.0" "1.3.0.1".


(*) Pada level rilis. Mungkin ada sub-cabang proyek pada masing-masing.


Terima kasih untuk ini. Saya menerima jawaban berbeda yang lebih sesuai dengan pikiran saya, tetapi ini adalah informasi yang baik jika Anda menggunakan cabang sedikit lebih banyak.
dave4351

1

Jika Anda menjual perangkat lunak maka Anda akan memiliki rilis besar baru setiap kali penjualan / pemasaran perlu mendapatkan bonus yang lebih besar :-).

Jika Anda memiliki kontrol maka:

  1. Rilis besar saat:

    • Ada beberapa ketidakcocokan dengan rilis sebelumnya yang memerlukan konversi dll. Seperti dari Python 2 ke Python 3.

    • Ada seluruh fungsionalitas baru.

  2. Rilis minor untuk setiap perubahan kecil dalam fungsionalitas.

  3. Rilis tambalan untuk perbaikan bug.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.