Kapan saya harus menambah nomor versi?

23

Saya tidak belajar pemrograman di sekolah dan saya tidak bekerja sebagai pengembang (profesional), oleh karena itu banyak dasar yang tidak begitu jelas bagi saya. Pertanyaan ini mencoba mengklarifikasi salah satunya.

Sekarang mari kita anggap bahwa saya memiliki masalah #1, #2dan #3dalam Pelacak Isu saya yang diatur untuk diperbaiki / ditingkatkan untuk versi 1.0.0dan bahwa versi (stabil) terakhir adalah 0.9.0.

Kapan saya harus menambah versi 1.0.0? Kapan a) hanya satu dari masalah di atas yang ditutup atau b) ketika semua masalah yang terkait dengan versi 1.0ditutup?

Yang mana cara yang benar untuk melakukannya? Dan dengan cara yang benar , maksud saya apa yang saat ini digunakan dalam industri.

versioning semantic-versioning

— ahmed
sumber

22

Lihat semver.org

— Martijn Pieters

1

Dan Anda dapat memasukkan ketiga masalah dalam rilis berikutnya juga.

— Martijn Pieters

Ya, saya sudah menggunakan SemVer dan SEMUA tiga masalah akan dirilis pada rilis berikutnya :)

— ahmed

Saya mengedit pertanyaan untuk menghindari kebingungan.

— ahmed

14

Saya dapat memberitahu Anda bagaimana saya melakukannya di tempat kerja.

Kami memiliki server integrasi berkelanjutan yang membuat, menguji, memberi tag, dan mengeluarkan paket versi. Kami hanya melanjutkan ke tahap berikutnya jika yang sebelumnya% 100 berhasil.

Versi kami terlihat seperti ini: <Versi Utama>. <Versi Kecil>. <Nomor Pembuatan>

Setiap build yang berhasil tanpa perbaikan bug atau peningkatan fitur akan menambah Nomor Build.
Setiap pembangunan yang berhasil dengan perbaikan bug yang lengkap atau peningkatan fitur akan meningkatkan Versi Minor. Ini secara otomatis dideteksi oleh keberadaan pesan komit menggunakan format tertentu. Pesan komit ini juga secara otomatis ditarik ke proyek ChangeLog.
Setiap kenaikan Versi Utama dilakukan dengan tangan ketika kami memiliki perubahan yang tidak kompatibel, penulisan ulang dari awal atau alasan lain yang dibuat berdasarkan kasus per kasus.

— dietbuddha
sumber

Tetapi jika Anda memiliki serangkaian perangkat tambahan yang harus diselesaikan pada <Minor Version>, 1.0.0 misalnya. Apakah Anda perlu melakukan SEMUA perangkat tambahan ini untuk dapat mengatakan "OK! Sekarang ini versi 1.0.0" atau Anda naik ke versi 1.0.0 segera setelah peningkatan pertama dilakukan?

— ahmed

@ ahmed Saya telah melihat pendekatan yang 1.4.2"set perbaikan ini, dan apa pun yang siap pada saat itu" ... Saya juga melihat 1.4.2sebagai "Ini akan dirilis pada tanggal ini dengan apa pun yang siap". Itu tergantung pada siklus rilis Anda.

5

@ ahmed Jika kriteria untuk beralih dari 0.xx ke 1.xx adalah penyelesaian dari set fitur / perbaikan maka saya hanya akan bertambah setelah semuanya selesai. Catatan: kita sama sekali tidak bekerja. Kami tidak menargetkan versi dan memutuskan perbaikan apa yang ada di dalamnya. Kami menargetkan perbaikan. Versi yang kami dapatkan adalah murni untuk pelacakan dan identifikasi bukan tujuan.

— dietbuddha

Inilah yang ingin saya ketahui :)

— ahmed

21

Nomor versi hanya relevan untuk rilis , karena ini adalah cara bagi pengguna eksternal untuk mengidentifikasi perangkat lunak Anda. Jika Anda hanya sibuk melakukan pengembangan dan tidak merilis setiap perbaikan secara individual, maka jangan khawatir tentang penambahan nomor rilis untuk setiap perbaikan. Ini tidak relevan untuk pengguna eksternal dan menghabiskan waktu Anda sendiri dengan pembukuan versi ekstra.

— Greg Hewgill
sumber

Apakah ini juga berlaku untuk pengembangan web di mana rilis dapat menjadi perbaikan terbaru sederhana untuk bug kecil?

— ahmed

4

Apakah Anda melakukan QA sebelum mengeluarkan perbaikan terbaru? Ini rilis. Jika bukan dari produk lengkap, maka dari perbaikan terbaru.

— Peter K.

@ahmed Dalam skenario seperti itu, nomor versi sering kali tidak terlihat oleh pengguna dan karenanya tidak berarti (nomor rilis terutama ada untuk pemasaran dan dukungan teknis, keduanya tidak berlaku untuk banyak webapps). Hanya menggunakan ID komit mungkin cukup. Jika Anda bersikeras menggunakan nomor versi, ya, saya mungkin akan meningkatkan tambalan.

— amon

Saya belajar banyak hal di sini: p Jadi, untuk meringkasnya: Saya TIDAK perlu nomor versi karena ID komit sudah cukup, karena SEMUA pengguna tetap akan menggunakan versi terakhir.

— ahmed

2

Meskipun semua pengguna berada di versi yang sama, pada saat Anda melihat laporan cacat, versi akan pindah. Anda masih memerlukan cara untuk mengikat laporan ke versi tertentu dari perangkat lunak (tanggal / waktu mungkin cukup baik).

— mattnz

2

Untuk aplikasi web yang digunakan secara terus-menerus, kita cenderung membangun angka-angka build menggunakan symver di muka dan tailing angka bangun, yaitu: 2.5.3.4328 di mana 4328 berasal dari sistem integrasi terus-menerus. Harapan umum adalah bahwa angka-angka berubah dengan langkah-langkah yang disengaja tetapi nomor build adalah ID unik yang sebenarnya.

Apa yang tampaknya dilakukan di sini adalah menangkap hari penempatan dan nomor build svn terkait:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Untuk apa nilainya.

— Wyatt Barnett
sumber

0

Jawaban lain sudah bagus, jadi saya hanya akan menambahkan di atasnya. Jika perangkat lunak Anda tidak dirilis dan Anda tidak benar-benar membutuhkan versi publik (versi non-publik adalah VCS Anda), maka tambahkan kata kunci " SNAPSHOT " di akhir versi Anda. Beberapa sistem, terutama dalam manajemen dependensi, memperlakukan snapshot secara berbeda dari versi yang dirilis karena mereka membandingkan tanggal perubahan snapshot daripada nomor versi. Jadi jika Anda memiliki v. 1.0.0-SNAPSHOT mulai jam 8 pagi dalam paket repo dan pengunduh dependensi lokal memiliki versi yang sama dari jam 7 pagi, itu akan mengunduh unduh yang diperbarui dari repo.

Seperti yang dikatakan di atas, versi pribadi Anda disediakan oleh sistem kontrol versi Anda (git, svn dll.).

— Hubert Grzeskowiak
sumber

0

Ada cukup kata tentang teori versi di sini sudut pandang lain.

Kapan saya harus naik ke versi 1.0.0?

Saya akan memfokuskan jawaban saya pada perubahan nomor versi utama.

Jawaban saya adalah: Pada dasarnya ketika Anda siap untuk itu. Beralih dari 0,9 ke 1,0 adalah hal besar, karena persepsi publik adalah bahwa Anda beralih dari produk beta ke rilis resmi.

(Saya akan berasumsi bahwa ini adalah produk komersial dari suatu perusahaan).

Beberapa pertanyaan sebelum beralih dari 0,9 ke 1,0.

Apakah organisasi Anda punya waktu untuk memberi tahu semua klien Anda saat ini. Untuk mengadakan sebuah pesta. Dapatkan banyak permintaan dukungan. Manajer akun untuk menjual produk Anda? Dll.

Ya saya melihat versi sebagai alat pemasaran dan jika Anda melihat-lihat Anda melihat bahwa itu pada dasarnya adalah standar industri.

Perusahaan kami beralih dari versi 2.x ke 3.0 dan mengadakan pesta yang hebat, menciptakan banyak desas-desus dan karena itu mendapat beberapa klien baru. Terlepas dari beberapa pembaruan antarmuka perbedaan antara versi cukup kecil.

— Pieter B
sumber