Kapan sebuah komit tidak boleh ditandai versi?

30

Konteks: Baru-baru ini saya mengetahui tentang Semantic Versioning , dan saya sedang berusaha menentukan cara terbaik untuk menggunakannya secara praktis untuk proyek saya sendiri.

Mengingat semver mengambil perubahan besar, perubahan kecil, dan tambalan ke dalam akun untuk versi, kapan komit tidak boleh ditandai dengan versi yang diperbarui? Tampaknya bagi saya bahwa setiap perubahan akan masuk ke dalam salah satu kategori ini, dan setiap perubahan harus diversi, tetapi ketika saya melihat berbagai proyek populer di GitHub, ini sepertinya bukan cara yang dilakukan (hanya dengan melihat fakta bahwa proyek besar memiliki puluhan ribu komitmen, dengan hanya ratusan tag).

— VortixDev
sumber

23

Apakah setiap komitmen untuk menguasai rilis yang stabil, teruji, berkualitas terjamin dalam proyek Anda?

— Alex Reinking

1

@AlexReinking Setiap komit diuji, tetapi saya hanya mencoba membiasakan diri dengan praktik umum dengan proyek pribadi saya, jadi hanya saya yang mengerjakannya dan karenanya tidak ada sistem yang benar-benar ada selain "buat perubahan, uji itu sendiri, lakukan itu ".

— VortixDev

Perhatikan juga bahwa tag dapat diubah nanti. Satu-satunya pengidentifikasi komit solid rock adalah kunci hash komit.

— Thorbjørn Ravn Andersen

9

setiap komit untuk dikuasai ??? Anda seharusnya tidak pernah berkomitmen untuk menguasainya. Setiap gabungan untuk dikuasai terdengar jauh lebih baik.

— xyious

2

Saya pikir @xyious mengenai kuku di kepala. Setiap komit yang berakhir pada master harus ditandai dengan versi karena setiap komit pada master harus merupakan rilis gabungan dari pengembangan .

— BJ Myers

71

SemVer menyangkut rilis versi , bukan komitmen . Jika model kontrol versi Anda mengharuskan setiap komit untuk dikuasai menjadi rilis, maka ya, setiap komit perlu ditandai sesuai dengan tingkat perubahannya.

Namun, secara umum, proyek mengembangkan produk yang sebagian besar stabil pada master dan menandai rilis yang mereka anggap layak untuk didukung. Ketika mereka melakukannya, mereka akan menandai sesuai dengan skema versi mereka, yang tidak harus SemVer pada khususnya.

— Alex Reinking
sumber

5

SemVer sebagian besar hanya masuk akal untuk perpustakaan di mana pengguna adalah bit kode lain dan bukan manusia. Sebenarnya tidak ada perubahan "pemutusan" di sebagian besar aplikasi yang dihadapi pengguna karena pengguna dapat secara otomatis beradaptasi dengan versi yang baru.

— Qwertie

5

Saya berpendapat bahwa versi baris perintah dari aplikasi yang menghadap pengguna harus secara semantik versi karena flag dan format output mereka dapat berperilaku berbeda. Sedikit area abu-abu.

— Alex Reinking

5

@Qwertie Ekspektasi pengguna tidak seketat ekspektasi perangkat lunak tetapi ekspektasinya masih ada. Saya PASTI telah menggunakan banyak perangkat lunak yang telah mengeluarkan apa yang saya anggap 'melanggar' perubahan pada antarmuka atau fungsi mereka. Memutuskan apa yang merupakan rilis utama vs kecil tentu saja lebih subjektif daripada dengan perpustakaan, tetapi itu tidak selalu menjadi alasan untuk menghindarinya.

— Iron Gremlin

11

@Qwertie - tahan peningkatan. Berapa banyak orang yang masih menjalankan Windows dan Office versi lama yang lama?

— Alex Reinking

5

@Qwertie Mereka mungkin terinspirasi untuk dengan cermat membaca log perubahan atau dokumentasi sehingga mereka dapat menyesuaikan cara mereka menggunakan sistem untuk memanfaatkan fitur baru atau yang dimodifikasi, atau menemukan solusi untuk fitur yang telah dihapus. Ini adalah kasus yang sama, penggunaan perangkat lunak mereka perlu berubah karena perangkat lunak telah berubah, jadi Anda harus memberi tahu mereka tentang perubahan itu secara jelas.

— Iron Gremlin

11

Nomor versi dialokasikan untuk rilis. Secara umum tidak setiap komit harus berupa rilis. Ada beberapa alasan untuk ini.

Pertama saat Anda mengatakan Anda "menguji" setiap komit ada tingkat pengujian. Menjalankan tes otomatis pada satu mesin semuanya baik dan bagus, tetapi dalam perangkat lunak yang kompleks kemungkinan tidak akan menangkap setiap masalah. Beberapa masalah mungkin khusus perangkat keras atau konfigurasi, beberapa masalah mungkin lebih tentang pertimbangan manusia-subyektif daripada tentang persyaratan yang sulit diuji.

Kedua menabrak nomor versi utama harus menjadi tindakan yang langka. Ini pada dasarnya berarti bahwa segala sesuatu yang tergantung pada perangkat lunak Anda perlu diperiksa secara manual untuk melihat apakah itu tergantung pada salah satu fitur yang dihapus.

Konsekuensi dari hal ini adalah Anda seharusnya hanya menambahkan fitur ke "API publik" Anda dalam rilis penuh (bukan alfa / beta) jika Anda siap untuk mendukung fitur-fitur tersebut dalam bentuk jangka panjang.

Ketiga sangat membantu untuk menjaga agar jumlah versi dalam penggunaan luas tetap rendah. Bahkan pada cabang yang stabil seringkali lebih baik untuk mengumpulkan sejumlah perbaikan bersama dan membuat satu rilis daripada membuat rilis untuk setiap perbaikan.

— Peter Green
sumber

2

Tampak jelas untuk mengatakan, tetapi: tujuan nomor versi adalah untuk memudahkan Anda menentukan versi perangkat lunak yang dijalankan siapa pun.

Jika ada kemungkinan ada orang yang memiliki akses ke iterasi tertentu dari kode, dan sebaliknya tidak dapat dengan mudah menentukan pengidentifikasi unik, maka iterasi harus memiliki nomor versi yang unik. Saya melihat ini sebagai 'aturan pertama'. Sebagai akibatnya, rilis yang berbeda jelas akan menginginkan nomor versi yang berbeda.

Namun, lebih banyak berperan:

Satu cara untuk memastikan hal ini adalah dengan menabrak nomor versi dengan setiap komit tetapi ini biasanya bukan ide yang baik. Mungkin diperlukan beberapa komitmen / iterasi untuk mendapatkan perubahan yang relatif kecil, dan membingungkan bagi dunia luar untuk melihat versi 0.0.1 -> 0.0.2 sebagai hasil dari sejumlah besar akumulasi perubahan kemudian 0.0.2 -> 0.0 0,56 karena seseorang yang melakukan spasi putih memperbaiki satu file pada satu waktu dan tidak mengubah apa pun yang fungsional.

Seberapa jauh dari "satu versi per rilis penuh" ke "satu versi untuk setiap komit" benar-benar terserah: Anda, pengguna lain, dan sistem apa yang Anda ingin gunakan untuk mengisi kesenjangan.

Saya pribadi terbiasa mengerjakan proyek-proyek kecil, dan saya senang menggunakan hash git hingga versi yang digunakan orang lain dan versi benjolan untuk masing-masing (tidak peduli berapa sedikit orang yang saya harapkan untuk mendapatkannya). Namun di perusahaan yang lebih besar dan proyek yang lebih besar sesuatu di luar nomor versi semantik, tetapi kesetiaan yang lebih rendah daripada komitmen masing-masing, seperti penomoran kandidat rilis digunakan. Ini memiliki kelebihan tetapi menambah kompleksitas.

— Sendirian
sumber

0

Setiap permintaan tarikan yang digabungkan untuk dikuasai harus diversi.

Jika seharusnya bukan versi baru (setidaknya tambalan), kemungkinan tidak boleh digabungkan untuk dikuasai karena fitur / perbaikan / dll tidak lengkap.

Namun, tergantung pada alur kerja tim Anda, Anda mungkin masih berakhir dengan beberapa komitmen untuk dikuasai tanpa versi. Jika ada beberapa komit dalam permintaan tarik yang tidak tergencet (Menurut saya seharusnya), Anda mungkin masih memiliki 10 komit dan hanya 1 versi baru.

— xyious
sumber