pengembangan-web-mp-pd.com

Apa yang angka-angka dalam versi biasanya wakili (yaitu v1.9.0.1)?

Mungkin ini adalah pertanyaan konyol, tetapi saya selalu mengasumsikan setiap angka yang digambarkan oleh suatu periode mewakili satu komponen perangkat lunak. Jika itu benar, apakah mereka pernah mewakili sesuatu yang berbeda? Saya ingin mulai menetapkan versi ke berbagai versi perangkat lunak saya, tetapi saya tidak begitu yakin bagaimana itu harus disusun. Perangkat lunak saya memiliki lima komponen berbeda.

110
BeachRunnerFred

Dalam versi 1.9.0.1:

  • 1 : Revisi utama (UI baru, banyak fitur baru, perubahan konseptual, dll.)

  • 9 : Revisi kecil (mungkin perubahan ke kotak pencarian, 1 fitur ditambahkan, koleksi perbaikan bug)

  • 0 : Rilis perbaikan bug

  • 1 : Bangun nomor (jika digunakan) —itu sebabnya Anda melihat kerangka .NET menggunakan sesuatu seperti 2.0.4.2709

Anda tidak akan menemukan banyak aplikasi turun ke empat level, 3 biasanya cukup.

159
Dillie-O

Ada Spesifikasi Versi Semantik

Ini adalah ringkasan dari versi 2.0:

Diberi nomor versi MAJOR.MINOR.PATCH, menambah:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Label tambahan untuk pra-rilis dan bangun metadata tersedia dalam ekstensi ke format MAJOR.MINOR.PATCH.

14
magyk

Ini bisa sangat sewenang-wenang, dan berbeda dari produk ke produk. Misalnya, dengan distribusi Ubuntu, 8.04 merujuk ke 2008.April

Biasanya angka paling kiri (utama) menunjukkan rilis besar, dan semakin jauh Anda pergi ke kanan, semakin kecil perubahan yang terlibat.

13
rkabir
11

Bilangan dapat bermanfaat seperti dijelaskan oleh jawaban lain, tetapi pertimbangkan bagaimana bilangan tersebut juga agak tidak berarti ... Sun, Anda tahu Sun, Java: 1.2, 1.3, 1.4 1.5 atau 5 lalu 6 . Dalam Apple II yang baik dan lama nomor versi Dimaksudkan Sesuatu. Saat ini, orang-orang menyerah pada nomor versi dan pergi dengan nama-nama konyol seperti "Feisty fig" (atau sesuatu seperti itu) dan "hardy heron" dan "europa" dan "ganymede". Tentu saja ini jauh kurang berguna karena, Anda akan kehabisan bulan jupiter sebelum Anda berhenti mengubah program, dan karena tidak ada pemesanan yang jelas Anda tidak dapat mengetahui mana yang lebih baru.

8
stu

Semakin banyak poin, semakin kecil rilisnya. Tidak ada standar solid yang nyata di luar itu - dapat berarti hal-hal yang berbeda berdasarkan apa yang diputuskan oleh pengelola proyek.

WordPress, misalnya, mengikuti garis-garis ini:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 hingga 2.0 akan menjadi rilis besar - fitur, perubahan antarmuka, perubahan besar pada API, kerusakan beberapa 1,6 templat dan plugin, dll. 2.0.2 hingga 2.1 akan menjadi rilis signifikan - fitur baru, secara umum.

7
ceejayoz

Angka dapat berarti apa saja yang Anda inginkan, meskipun angka-angka itu biasanya tidak terkait dengan komponen individual tetapi lebih kepada perubahan besar vs. kecil vs pemeliharaan dalam rilis Anda.

Lihat sumber daya ini:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Tepuk tangan

4
Alvaro Rodriguez

Nomor versi biasanya tidak mewakili komponen yang terpisah. Untuk beberapa orang/perangkat lunak angkanya cukup sewenang-wenang. Bagi yang lain, bagian berbeda dari string nomor versi memang mewakili hal yang berbeda. Sebagai contoh, beberapa sistem meningkatkan bagian dari nomor versi ketika format file berubah. Jadi V 1.2.1 adalah format file yang kompatibel dengan semua versi V 1.2 lainnya (1.2.2, 1.2.3, dll.) Tetapi tidak dengan V 1.3. Pada akhirnya terserah Anda skema apa yang ingin Anda gunakan.

3
user9385

Dari file C # AssemblyInfo.cs Anda dapat melihat yang berikut:

// Version information for an Assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [Assembly: AssemblyVersion("1.0.*")]
2
Thomas Jespersen

release.major.minor.revision akan menjadi tebakan saya.
Tapi itu bisa sangat bervariasi antara produk.

2
Fire Lancer

Itu tergantung, tetapi representasi tipikal adalah major.minor.release.build.

Dimana:

  • major adalah versi rilis utama dari perangkat lunak Anda, pikirkan .NET 3.x
  • minor adalah versi rilis kecil dari perangkat lunak Anda, pikirkan .NET x.5
  • release adalah rilis versi itu, biasanya perbaikan bug akan meningkatkan ini
  • build adalah angka yang menunjukkan jumlah build yang telah Anda lakukan.

Jadi misalnya, 1.9.0.1, berarti versi 1.9 dari perangkat lunak Anda, mengikuti 1.8 dan 1.7, dll. Di mana 1.7, 1.8 dan 1.9 semuanya dengan cara tertentu biasanya menambahkan sejumlah kecil fitur baru bersama perbaikan bug. Karena ini x.x.0.x, ini merupakan rilis awal 1.9, dan ini merupakan versi pertama dari versi itu.

Anda juga dapat menemukan informasi yang baik tentang artikel Wikipedia tentang subjek .

Major.Minor.Bugs

(Atau beberapa variasi tentang itu)

Bug biasanya merupakan perbaikan bug tanpa fungsi baru.

Minor adalah beberapa perubahan yang menambah fungsionalitas baru tetapi tidak mengubah program dengan cara apa pun.

Mayor adalah perubahan dalam program yang merusak fungsi lama atau sangat besar sehingga entah bagaimana mengubah cara pengguna harus menggunakan program.

2
emeryc

Semua orang memilih apa yang ingin mereka lakukan dengan angka-angka ini. Saya tergoda untuk memanggil rilis a.b.c karena itu agak konyol. Yang sedang berkata, apa yang saya lihat selama 25 + tahun terakhir pembangunan cenderung bekerja seperti ini. Katakanlah nomor versi Anda adalah 1.2.3.

"1" menunjukkan revisi "besar". Biasanya ini adalah rilis awal, perubahan set fitur besar atau penulisan ulang bagian signifikan dari kode. Setelah set fitur ditentukan dan setidaknya sebagian diimplementasikan Anda pergi ke nomor berikutnya.

"2" menunjukkan rilis dalam suatu seri. Seringkali kita menggunakan posisi ini untuk terjebak pada fitur yang tidak membuatnya dalam rilis besar terakhir. Posisi ini (2) hampir selalu menunjukkan penambahan fitur, biasanya dengan perbaikan bug.

"3" di sebagian besar toko menunjukkan rilis patch/perbaikan bug. Hampir tidak pernah, setidaknya di sisi komersial, apakah ini menunjukkan penambahan fitur yang signifikan. Jika fitur muncul di posisi 3 maka itu mungkin karena seseorang memeriksa sesuatu sebelum kami tahu kami harus melakukan rilis perbaikan bug.

Di luar posisi "3"? Saya tidak tahu mengapa orang melakukan hal semacam itu, hanya saja semakin membingungkan.

Khususnya beberapa OSS di luar sana melempar semua ini begitu saja. Misalnya, Trac versi 10 sebenarnya 0,10.X.X. Saya pikir banyak orang di dunia OSS kurang percaya diri atau hanya tidak ingin mengumumkan bahwa mereka memiliki rilis besar.

1
mclain

Orang-orang tidak selalu mengenali perbedaan halus antara nomor versi seperti 2.1, 2.0.1, atau 2.10 - tanyakan pada orang dukungan teknis berapa kali mereka mengalami masalah dengan ini. Pengembang berorientasi pada detail dan terbiasa dengan struktur hierarkis, jadi ini adalah titik buta bagi kami.

Jika memungkinkan, buka nomor versi yang lebih sederhana untuk pelanggan Anda.

1
Mark Ransom

Paradigma rilis release.minor utama. Perbaikan bug cukup umum, saya pikir. 

Dalam beberapa kontrak dukungan perusahaan ada $$$ (atau pelanggaran kewajiban kontrak) yang terkait dengan bagaimana rilis tertentu ditetapkan. Sebuah kontrak, misalnya, mungkin memberikan hak kepada pelanggan untuk sejumlah rilis besar dalam periode waktu tertentu, atau berjanji bahwa akan ada lebih sedikit dari x jumlah rilis kecil dalam suatu periode, atau bahwa dukungan akan terus tersedia untuk begitu banyak rilis. Tentu saja tidak peduli berapa banyak kata yang dimasukkan ke dalam kontrak untuk menjelaskan apa rilis utama versus rilis kecil, selalu subyektif dan akan selalu ada daerah abu-abu - yang mengarah ke kemungkinan bahwa vendor perangkat lunak dapat memainkan sistem untuk mengalahkan ketentuan kontrak tersebut.

1
Will M

Dalam kasus perpustakaan, nomor versi memberi tahu Anda tentang tingkat kompatibilitas antara dua rilis, dan dengan demikian betapa sulitnya peningkatan.

Rilis perbaikan bug perlu menjaga kompatibilitas biner, sumber, dan serialisasi.

Rilis minor memiliki arti yang berbeda untuk proyek yang berbeda, tetapi biasanya mereka tidak perlu menjaga kompatibilitas sumber.

Nomor versi utama dapat memecah ketiga bentuk.

Saya menulis lebih banyak tentang alasan di sini .

1
Craig P. Motlin

Major.minor.point.build biasanya. Mayor dan minor cukup jelas, point adalah rilis untuk beberapa perbaikan bug minor, dan build hanyalah pengidentifikasi build.

1
Cody Brocious

Biasanya ini:

MajorVersion.MinorVersion.Revision.Build

1
Jason Punyon

Ya. Rilis besar menambah fitur besar, baru, dapat merusak kompatibilitas atau memiliki ketergantungan yang sangat berbeda, dll.

Rilis minor juga menambahkan fitur, tetapi lebih kecil, terkadang versi porting yang dilucuti dari rilis beta mayor.

Jika ada komponen nomor versi ketiga, biasanya untuk perbaikan bug penting, dan perbaikan keamanan. Jika ada lebih banyak, itu sangat tergantung pada produk sehingga sulit untuk memberikan jawaban umum.

1
Paweł Hajdan

Nomor pertama biasanya disebut sebagai nomor versi utama. Ini pada dasarnya digunakan untuk menunjukkan perubahan signifikan antara build (mis. Ketika Anda menambahkan banyak fitur baru, Anda menambah versi utama). Komponen dengan versi utama yang berbeda dari produk yang sama mungkin tidak kompatibel.

Nomor berikutnya adalah nomor versi minor. Ini dapat mewakili beberapa fitur baru, atau sejumlah perbaikan bug atau perubahan arsitektur kecil. Komponen dari produk yang sama yang berbeda dengan nomor versi minor mungkin atau mungkin tidak bekerja bersama dan mungkin tidak boleh.

Berikutnya biasanya disebut nomor build. Ini mungkin bertambah setiap hari, atau dengan setiap build "dirilis", atau dengan setiap build sama sekali. Mungkin hanya ada perbedaan kecil antara dua komponen yang berbeda hanya dengan nomor build dan biasanya dapat bekerja sama dengan baik.

Nomor akhir biasanya nomor revisi. Sering kali ini digunakan oleh proses pembuatan otomatis, atau ketika Anda membuat build "sekali saja" untuk pengujian.

Ketika Anda menambah nomor versi Anda terserah Anda, tetapi mereka harus selalu kenaikan atau tetap sama . Anda dapat membuat semua komponen berbagi nomor versi yang sama, atau hanya menambah nomor versi pada komponen yang diubah.

0
Bob King

Nomor versi perangkat lunak kompleks mewakili seluruh paket dan tidak tergantung pada nomor versi bagian-bagiannya. Gizmo versi 3.2.5 mungkin berisi Foo versi 1.2.0 dan Bar versi 9.5.4.

Saat membuat nomor versi, gunakan itu sebagai berikut:

  1. Nomor pertama adalah rilis utama. Jika Anda membuat perubahan signifikan pada antarmuka pengguna atau perlu memecah antarmuka yang ada (sehingga pengguna Anda harus mengubah kode antarmuka mereka), Anda harus pergi ke versi utama baru. 

  2. Angka kedua harus menunjukkan bahwa fitur baru telah ditambahkan atau sesuatu bekerja secara internal berbeda. (Misalnya database Oracle mungkin memutuskan untuk menggunakan strategi yang berbeda untuk mengambil data, membuat sebagian besar hal lebih cepat dan beberapa hal lebih lambat.) Antarmuka yang ada harus terus bekerja dan antarmuka pengguna harus dikenali. 

  3. Penomoran versi lebih lanjut tergantung pada orang yang menulis perangkat lunak - Oracle menggunakan lima (!) Grup, yaitu. versi Oracle adalah sesuatu seperti 10.1.3.0.5. Dari grup ketiga ke bawah, Anda hanya boleh memperkenalkan perbaikan bug atau perubahan kecil dalam fungsionalitas. 

0
Sten Vesterli
0
Sijin

yang kurang bervariasi akan menjadi dua yang pertama, untuk major.minor, setelah itu dapat berupa apa saja dari build, revisi, rilis, hingga algoritma kustom apa pun (seperti pada beberapa produk MS)

0
BlackTigerX

Inilah yang kami gunakan:

  1. Angka pertama = Era sistem keseluruhan. Perubahan setiap beberapa tahun dan biasanya mewakili perubahan mendasar dalam teknologi, atau fitur klien atau keduanya.
  2. Angka kedua = revisi skema basis data. Peningkatan dalam jumlah ini membutuhkan migrasi basis data dan juga merupakan perubahan yang signifikan (atau sistem mereplikasi dan mengubah struktur basis data memerlukan proses peningkatan yang cermat). Ulang ke 0 jika angka pertama berubah.
  3. Angka ketiga = perubahan hanya perangkat lunak. Ini biasanya dapat diimplementasikan pada klien dengan klien sebagai skema database tidak berubah. Ulang ke nol jika angka kedua berubah.
  4. Nomor versi subversi. Kami mengisi ini secara otomatis di build menggunakan alat TortoiseSVN. Jumlah ini tidak pernah me-reset tetapi terus bertambah. Menggunakan ini, kami selalu dapat membuat ulang versi apa pun.

Sistem ini melayani kita dengan baik karena setiap angka memiliki fungsi yang jelas dan penting. Saya telah melihat tim lain bergulat dengan pertanyaan nomor besar/minor (seberapa besar perubahan itu besar) dan saya tidak melihat manfaatnya. Jika Anda tidak perlu melacak revisi basis data, buka nomor versi 3 atau 2 digit, dan buat hidup lebih mudah!

0
Ewan Makepeace

Dalam versi v1.9.0.1: Ini adalah skema versi eksplisit yang digunakan ketika Anda tidak ingin menggunakan nama untuk pra-rilis atau membangun seperti -alpha, -beta.

1: Versi utama yang mungkin merusak kompatibilitas ke belakang

9: Menambahkan fitur baru untuk mendukung aplikasi Anda bersamaan dengan kompatibilitas mundur dengan versi sebelumnya.

0: Beberapa perbaikan bug minor

1: Nomor pembuatan (Nomor pra-rilis)

tetapi saat ini, Anda tidak akan menemukan skema versi seperti itu. Rujuk Versi Semantik [semver2.0] https://semver.org/

0
Mehul Sancheti

Setiap organisasi/kelompok memiliki standar sendiri. Yang penting adalah Anda tetap berpegang pada notasi apa pun yang Anda pilih jika tidak pelanggan Anda akan bingung. Setelah mengatakan bahwa saya biasanya menggunakan 3 angka:

x.yz.bbbbb. Di mana: X: adalah versi utama (fitur baru utama) Y: adalah nomor versi minor (fitur baru kecil, peningkatan kecil tanpa perubahan UI) Z: adalah paket layanan (pada dasarnya sama Sebagai xy tetapi dengan beberapa perbaikan bug.

0
Vasco Duarte

Kombinasi major, minor, patch, build, patch keamanan, dll.

Dua yang pertama adalah mayor & minor - sisanya tergantung pada proyek, perusahaan, dan terkadang komunitas. Dalam OS seperti FreeBSD, Anda akan memiliki 1.9.0.1_number untuk mewakili patch keamanan.

0
Loren Segal

Tergantung sedikit pada bahasa, Delphi dan C # misalnya memiliki arti berbeda.

Biasanya, dua angka pertama mewakili versi utama dan versi minor, yaitu 1.0 untuk rilis nyata pertama, 1.1 untuk beberapa perbaikan bug penting dan fitur baru minor, 2.0 untuk rilis fitur baru yang besar.

Angka ketiga dapat merujuk ke versi "sangat kecil", atau revisi. 1.0.1 hanyalah perbaikan bug yang sangat kecil untuk 1.0.0 misalnya. Tetapi juga dapat membawa nomor Revisi dari Sistem Kontrol Sumber Anda, atau angka yang terus bertambah yang bertambah dengan setiap build. Atau Datestamp.

Sedikit lebih detail sini . "secara resmi", di .net, 4 angka adalah "Major.Minor.Build.Revision", sedangkan di Delphi ada "Major.Minor.Release.Build". Saya menggunakan "Major.Minor.ReallyMinor.SubversionRev" untuk versi saya.

0
Michael Stum

Secara umum, maka angka dalam format versi.major.minor.hotfix, bukan komponen internal individual. Jadi v1.9.0.1 adalah versi 1, rilis mayor 9 (dari v1), rilis minor (dari v1.9) 0, hot fix 1 of (v1.9.0).

0
Scott Bevington