Apa yang digunakan sebagai versi awal? [Tutup]


122

Saya biasanya memulai proyek saya dengan versi 1.0.0. Segera setelah saya memiliki beberapa item, saya merilisnya sebagai 1.0.0 dan melanjutkan dengan 1.1.0.

Namun, ini mengarah pada dapat digunakan tetapi tidak sepenuhnya menampilkan versi lengkap 1.0.0 dari kebanyakan hal yang saya tulis. Saya kemudian menambahkan fitur dan mendapatkan versi yang layak sekitar 1.6.0. Banyak proyek dimulai dengan versi 0.1.0, yang akan sama bermanfaatnya dengan 1.0.0 saya.

Apa yang akan Anda sarankan untuk lakukan? Mulai dengan 1.0.0 atau 0.1.0?

Nomor terakhir hanya untuk rilis perbaikan bug. Anda dapat menganggap 1.0.0 saya sebagai 1.0 dan 0.1.0 sebagai 0.1 adalah yang lebih mudah bagi Anda.


1
Saya baru tahu tentang "semantic versioning" ( semver.org ), itulah yang ingin saya lakukan. Namun, saya tidak membuat API dan ini berbicara tentang API, jadi saran 1.0.0 tidak benar-benar berlaku.
Noarth


Jawaban:


-24

Pembuatan versi saya didorong oleh penyiapan. Saya ingin itu menggantikan versi lama, jadi saya terus meningkatkannya dalam lompatan yang masuk akal bagi saya.

Terkadang, bagaimanapun, pembuatan versi didorong oleh pelanggan, terutama jika Anda merilis kode ke publik.

Jika itu keputusan Anda, lakukan apa pun yang terbaik untuk Anda. Saya memiliki beberapa masalah dengan versi sebelum 1.0 jadi saya mulai dengan itu.


1
Anda tidak benar-benar menjelaskan apa pun dalam jawaban Anda. Anda tidak menyebutkan masalah apa yang Anda miliki, jadi kami dapat membahasnya. Anda tidak menjelaskan kapan dan mengapa versi tersebut didorong oleh pelanggan, yang bagaimanapun juga bukan OP. Dan Anda tidak menjelaskan bagaimana dan mengapa pembuatan versi didorong oleh penyiapan. Apa yang Anda maksud dengan itu, dengan cara yang penting untuk jawabannya? Jawaban yang terdefinisi dengan baik harus menyertakan kekurangan dan kelebihan dari setiap keputusan, Anda hanya menyertakan alasan yang tidak jelas :).
Eksapsy

225

Standar Semantic Versioning 2.0.0 mengatakan:

Hal paling sederhana yang harus dilakukan adalah memulai rilis pengembangan awal Anda di 0.1.0 dan kemudian menaikkan versi minor untuk setiap rilis berikutnya.

Tidak masalah untuk beralih dari 0.3.0 langsung ke 1.0.0. Juga sangat oke untuk berada di 0.23.0. Mulai dari 0.4.0 agak tidak disarankan karena menunjukkan ada versi yang diterbitkan sebelumnya.

Selain itu, perhatikan yang 0.y.zdisisihkan untuk iterasi cepat, sehingga pengembangan awal (dan karenanya banyak perubahan yang merusak) tidak membuat Anda pada sesuatu yang konyol seperti 142.6.0. Daripada mengganti versi mayor, ubah versi minor pada setiap perubahan yang melanggar sampai Anda merilis 1.0.0:

Versi utama nol (0.yz) adalah untuk pengembangan awal. Apa pun bisa berubah sewaktu-waktu. API publik seharusnya tidak dianggap stabil.


Ini HARUS menjadi jawaban yang diterima. Tidak pernah melihat jawaban dengan 16 suara negatif sebagai jawaban yang
diterima

Ada jebakan jika Anda menggunakan npm. Jika Anda mulai dengan 0, tanda sisipan "^" di package.json akan berlaku berbeda. docs.npmjs.com/misc/semver#caret-ranges-123-025-004 Anda dapat menggunakan 0.x sebagai ganti ^ 0. dalam paket json untuk skenario ini. Oleh karena itu, 1.x sedikit lebih mudah untuk dimulai dan digunakan.
Sam

9

Nomor versi sepenuhnya terserah Anda. Lakukan apa yang masuk akal bagi Anda dan bersikaplah konsisten. Tidak ada yang mengatakan Anda harus mulai dari 0, atau 0.0, atau 1.0, atau 1.1.

Pemrogram hebat sebenarnya menggunakan sistem penomoran versi sebagai lelucon lokal. Contoh (Wikipedia):

Sejak versi 3, TeX telah menggunakan sistem penomoran versi idiosinkratik, di mana pembaruan telah ditunjukkan dengan menambahkan digit tambahan di akhir desimal, sehingga nomor versi secara asimtotik mendekati π. Ini adalah cerminan dari fakta bahwa TeX sekarang sangat stabil, dan hanya pembaruan kecil yang diantisipasi. Versi TeX saat ini adalah 3.1415926; itu terakhir diperbarui pada Maret 2008

Untuk METAFONT:

Metafont memiliki sistem versi yang mirip dengan TeX, di mana jumlahnya mendekati e secara asimtotik dengan setiap revisi.

Akhirnya, bukan nomor versi, tapi sama menariknya, adalah bahwa penawaran umum perdana (IPO) Google diajukan ke SEC untuk mengumpulkan $ 2.718.281.828 (perhatikan bahwa e ~ 2.718 281 828).

Maksud saya adalah: jangan merasa bahwa Anda perlu mengikuti orang banyak. Jadilah kreatif dan konsisten.


6

Saya pikir berbagai faktor ikut bermain di sini. Dampak psikologis / pemasaran dari nomor versi (nomor versi sering bertambah => lebih banyak $$$, orang tidak ingin membeli versi beta 0.99, dll) harus diperhitungkan. Nomor versi "Logika" dapat membantu saat bekerja dalam tim besar.

Dan saya suka cara linux memiliki angka ganjil untuk versi yang tidak stabil, dan angka genap untuk versi stabil.


1

Ketika saya mendapatkan yang dapat digunakan pertama saya siap tetapi bukan versi lengkap fitur, saya biasanya mencoba untuk menilai sejauh mana itu menuju versi lengkap fitur, jadi misalnya jika penggunaan pertama saya adalah 33% fitur selesai saya membuat nomor versi 0.3.0 atau serupa. Kemudian saat saya beralih ke fitur lengkap versi yang sesuai, dapatkan nomor yang diberikan dengan cara yang sama.

Tapi begitu Anda beralih ke fitur masa lalu, versi lengkap perlu diubah


3
Itu entah bagaimana menyiratkan bahwa Anda hanya dapat mencapai 0.9.0, tetapi saya tahu banyak proyek yang berjalan seperti 0.25.0.
Noarth

Saya cenderung menggunakan set digit terakhir untuk perubahan tambahan kecil serta perbaikan bug, dan tetap menggunakan digit tengah untuk perubahan yang cukup besar sehingga tidak pernah benar-benar perlu memasukkan digit ganda untuk bilangan tengah
Tristan

1

Saat memilih nomor versi untuk sebuah npmpaket, ketahuilah bahwa untuk dependensi yang tercantum dalam package.json rentang semver tidak akan berfungsi di bawah v1.0.0. Itu adalah,

"dependencies": {
    "my-package": "^0.5"
}

setara dengan

"dependencies": {
    "my-package": "0.5"
}

Jika Anda ingin dapat menggunakan rentang semver, atau Anda ingin membiarkan orang lain menggunakannya, Anda mungkin ingin memulai dengan 1.0.0


Menarik. Apakah Anda memiliki informasi lebih lanjut tentang mengapa (atau di mana) rentang Semver tidak berfungsi di bawah 1.0.0? Karena ada beberapa paket menggunakan 0.0.xdalam registri NPM .
Remi

Saya tidak tahu mengapa orang-orang npm membuat keputusan itu, atau di mana dalam sistem npm itu dibuat / apa yang perlu diubah untuk mendukung rentang semver untuk versi kurang dari 1. Saya juga tertarik untuk mengetahuinya!
henry

3
Mereka membuat keputusan itu karena ^artinya "kompatibel dengan versi" . Lebih lengkapnya di sini . Semver, 0.y.zdimaksudkan untuk pengembangan awal dan setiap perubahan yatau zbisa jadi tidak kompatibel. Dalam contoh Anda ^0.5 := 0.5 := 0.5.x, jadi ini adalah rentang. Jika rentang tanda sisipan tidak berfungsi untuk Anda dalam 0.y.zrentang tersebut, Anda dapat menggunakan rentang pembanding, tanda hubung, x, dan tilde, selain rentang tanda sisipan.
dosentmatter

0

Biasanya, pembuatan versi memiliki arti bagi programmer. Meningkatkan angka utama mungkin menunjukkan perubahan besar yang mencegah kompatibilitas ke belakang. Nomor lain di nomor versi mungkin menunjukkan peningkatan fitur yang lebih kecil atau perbaikan bug.

Jika Anda khawatir versi 0.6.5 memiliki cincin yang tidak lengkap, Anda mungkin ingin memasarkannya di bawah versi 1.0. Nomor versi pemasaran Anda tidak harus sama dengan nomor versi internal Anda. Nomor versi Windows 7, misalnya, adalah 6.1.

Preferensi pribadi saya adalah mulai dari 0.1.0 dan pergi dari sana.


0

Tergantung proyeknya. Untuk alat baris perintah sederhana, saya biasanya mulai sekitar 0,9 [.0] karena saya hanya mempertimbangkan untuk merilis atau mengemasnya ketika hampir selesai (atau siap untuk pengujian beta.) Proyek yang lebih rumit dimulai sekitar 0,1 [.0] dan beberapa bahkan tidak pernah melihat 1.0. Saya menganggap 1.0 sebagai versi rilis (atau setidaknya beta atau kandidat rilis yang diuji secara lokal) dan merencanakannya sesuai dengan itu.

Dengan proyek tim, siapa pun yang meletakkan tag versi pertama akan memutuskan :).


0

0.1.0 adalah yang saya mulai dan naik dari sana. Inilah yang saya adaptasi untuk Xploration By Adrian, meskipun pada tahun-tahun awal saya, saya sangat sporadis dan menggunakan 1.0.0, 0.0.1, dan beberapa lainnya. Tetapi saya merekomendasikan mulai dari 0.1.0 dan pergi dari sana.

Per Semver, simpan a dan c di abc untuk A. Anda rilis resmi pertama dan C. Perbaikan bug dan tambalan. Ini karena versi mayor biasanya memecah kode yang lebih lama. Dan tambalan hanya memperbaiki bug. Ini semua adalah preferensi pribadi, 0.99.0 tidak berarti Anda harus pergi ke 1.0.0, dll. Saya telah melihat beberapa yang mengarah ke 0.218.42.


-1

Nomor versi harus berarti bagi Anda karena Arrieta berkomentar dengan benar sebelumnya.

Mungkin mengikuti sesuatu seperti: Pertama # adalah rilis mayor, # Kedua adalah rilis mayor yang sama dengan beberapa fitur yang ditambahkan dan Ketiga # adalah rilis mayor yang sama, dengan fitur yang sama tetapi dengan bug yang diperbaiki atau menambahkan sedikit perubahan (tetapi cukup signifikan).

1.3.2 => Rilis Pertama, dengan lebih banyak fitur dan beberapa bug diperbaiki.

Namun, untuk pengguna akhir, beberapa terbiasa dengan jumlah besar untuk rilis final.

Contoh: Corel 8, untuk 8.0.0, 8.0.1, 8.2.2, dll. Corel 9, untuk 9.0.0 ... dll.

Dan sebagian besar lebih banyak tentang strategi pemasaran seperti: Corel X5 daripada Corel 15.0.2 misalnya.

Saya akan mengatakan bahwa itu tergantung apakah nomor versinya untuk Anda atau untuk klien.


-4

mulai dengan 0.0.0 dan lanjutkan dari sana.


4
Apakah itu berarti Anda benar-benar akan melakukan rilis 0.0.0? Saya mulai dengan angka pertama yang akan saya rilis.
Noarth

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.