Apa yang dimaksud dengan versi pembaruan?

18

Banyak pembaruan perangkat lunak mengikuti skema v0.1 hingga v0.2 hingga v2.6.5.6 . Apa arti "pembaruan" perangkat lunak ini? Apakah ada standar industri yang selalu diikuti atau apakah pemrogram terus meningkatkan # pembaruan atau menambahkan lebih banyak desimal?

deployment software-updates software-distribution

— James Mertz
sumber

12

@ S.Lott Karena saya cukup baru di panggung pemrograman saya tidak akan tahu secara spesifik. Ini adalah cara terbaik untuk bertanya yang bisa saya lakukan.

— James Mertz

9

@ S.Lott, kurangi kafein Pak, itu membuat Anda jengkel.

— ocodo

2

@ S.Lott merasa bebas untuk mengedit sesuai keinginan untuk memperbaiki pertanyaan. Saya merasa Anda tahu apa yang saya cari. Namun, saya merasa bahwa jawaban yang diberikan sangat bagus. Saya juga merasa, menilai dengan suara-up pada komentar saya sebelumnya, bahwa saya telah melakukan yang terbaik yang saya bisa dan bahwa pertanyaannya tidak apa-apa. Namun saya menerima kritik, juga suntingan. Lakukan sesuai keinginan Anda. Bagi saya, saya meninggalkannya sendiri.

— James Mertz

1

@ S.Lott Pertanyaannya tampak cukup jelas bagi saya. Saya tidak berpikir mendaftar organisasi penulisan standar tertentu akan menjadi peningkatan yang cukup besar. Jika Anda merasa sebaliknya, jangan ragu untuk mengedit. Anda memiliki perwakilan untuk itu.

— Adam Lear

3

@ S.Lott: "Apakah ada standar industri" baik-baik saja. Ya, ada standar industri! Tidak masalah siapa yang menulisnya: KronoS ingin tahu apa arti versi, itu adalah pilihannya untuk menentukan seberapa rinci dia berjalan ... Mungkin Anda seharusnya menyebutkan bahwa Anda menganggap pertanyaan itu luas? Hanya memalu pada detail tidak membuat itu jelas bagi pengguna, memberitahu pengguna untuk mendefinisikan: kata tidak membuat jelas bagi pengguna, mengatakan itu tidak ada artinya setelah komentar pertama Anda tidak menjelaskan kepada pengguna.

— Tamara Wijsman

16

Seperti kata Shaun, sebenarnya tidak ada standar. Beberapa perusahaan memiliki praktik versi yang lebih baik daripada yang lain (saya sudah berurusan dengan vendor yang melewatkan nomor versi utama, dan yang lain terjebak pada beberapa rilis yang sama kemudian).

Karena itu, penemu Gravatar dan salah seorang pendiri GitHub ( Tom Preston-Werner ) menulis sebuah dokumen untuk ' Versi Semantik ' yang lebih dari layak dibaca.

Inilah pengecualian intro:

Sebagai solusi untuk masalah ini, saya mengusulkan serangkaian aturan dan persyaratan sederhana yang menentukan bagaimana nomor versi diberikan dan ditingkatkan. Agar sistem ini berfungsi, Anda harus mendeklarasikan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, penting bahwa API ini jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengkomunikasikan perubahan itu dengan peningkatan spesifik ke nomor versi Anda. Pertimbangkan format versi XYZ (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi penambahan API pada versi patch, penambahan / perubahan API yang kompatibel menambah versi minor, dan perubahan API yang tidak kompatibel yang mundur menambah versi utama.

Saya menyebut sistem ini "Versi Semantik." Di bawah skema ini, nomor versi dan cara perubahannya menyampaikan makna tentang kode yang mendasarinya dan apa yang telah dimodifikasi dari satu versi ke versi berikutnya.

— Dan McGrath
sumber

7

Dengan 4 digit biasanya MajorV.MinorV.PatchNum.BuildNum, setidaknya di tempat saya bekerja.

Saya pribadi lebih suka skema versi Ubuntu - membuat hidup jadi lebih mudah.

— Pekerjaan
sumber

Apa skema mereka? Mengapa Anda lebih suka mereka?

— James Mertz

3

Ubuntu 10,10 = Oktober 2010, Ubuntu 10,04 = April 2010, Ubuntu 11,04 = Aprial 2011, Ubuntu 9,10 = Oktober 2009, dll. Ini disebutkan dalam tautan Wikipedia oleh Shaun.

— Pekerjaan

2

Yang menyenangkan tentang menggunakan tanggal sebagai nomor versi adalah bahwa - kecuali jika terjadi paradoks waktu yang aneh - nomor versi Anda akan selalu berada dalam urutan yang benar. Bagi sebagian besar dari kita, lebih mudah untuk mengingat bahwa hari ini adalah 2011.02.13 daripada mencoba untuk mencari tahu apa versi rilis yang seharusnya.

— jmort253

@ jmort245, Tepat! Sistem buatan manusia sangat berantakan. Bank-bank yang ketakutan berpikir bahwa ada 360, 362, 365, 366, dll. Dalam setahun. Sistem versi adalah salah satu dari ciptaan bodoh itu. Stempel waktu tidak membuat kita berpikir, walaupun 20050207 membutuhkan waktu lebih lama untuk membaca dan mencari tahu dari 502. Perangkat lunak apa yang dirilis lebih sering dari sekali per bulan?

— Pekerjaan

2

@job: Tetapi menggunakan versi memungkinkan Anda untuk mengikat fitur ke versi mayor atau minor tertentu. Jadi, jika saya memiliki versi 2, saya tahu saya memiliki fitur X sementara versi 1 tidak memiliki versi X.

— Martin York

6

Versi singkatnya adalah tidak ada standar dan perusahaan melakukan apa pun yang mereka inginkan. Pada dasarnya, semakin banyak angka yang Anda miliki, semakin kecil jumlah perubahan yang diwakili setiap angka. Secara umum, Anda akan melihat setidaknya versi xy, di mana xa perubahan dalam x menandakan rilis utama (peningkatan besar / peluncuran fitur) dan y menandakan rilis kecil (tweak signifikan atau perbaikan cacat). Semakin banyak desimal setelah kedua hal tersebut dapat berarti hal yang berbeda secara internal bagi perusahaan meskipun seringkali berkisar pada pengembangan konten kecil atau tambalan yang mewakili perbaikan yang lebih cepat dan lebih kecil.

Wikipedia memiliki artikel yang membahas hal ini secara lebih rinci.

— Shaun
sumber

3

Tujuan dari nomor versi adalah untuk memberikan referensi untuk laporan masalah. Satu-satunya persyaratan adalah bahwa setiap rilis memiliki nomor versi yang unik. Beberapa angka didorong oleh pemasaran - angka besar yang lebih besar lebih mudah dijual, dan angka daya seperti 10 (angka romawi X) benar-benar menarik. Beberapa orang menggunakan beberapa variasi versi semantik:

MAJOR.MINOR.MICRO.BUILD

Peningkatan besar: perubahan yang tidak kompatibel atau desain ulang lengkap UI
Peningkatan kecil: fitur baru ditambahkan, kompatibel dengan versi sebelumnya dalam nomor versi utama yang sama
Peningkatan mikro: rilis perbaikan bug
Nomor pembuatan: dihasilkan oleh kompiler atau ditarik dari kontrol versi

Banyak grup mengeluarkan nomor BUILD dalam rilis mereka. Biasanya hanya berguna antara kelompok pengujian dan pengembangan.

Beberapa kelompok menambahkan semantik tambahan, seperti kenaikan MINOR ganjil bernomor adalah untuk build eksperimental dan bahkan kenaikan MINOR bernomor genap adalah untuk rilis produksi ( Linux kernel menggunakan pendekatan ini).

Intinya adalah bahwa tidak ada standar, selain versi yang lebih baru menggunakan nomor versi yang lebih tinggi, dan setiap nomor versi unik.

— Berin Loritsch
sumber