Backbone: Ikuti SemVer

Terima kasih, tetapi mengikuti versi "semantik" dengan ketat tidak akan berhasil dengan baik untuk Backbone. Mengingat bahwa proyek ini hampir semua area permukaan, dan internal yang sangat sedikit, hampir semua perubahan yang diberikan (tambalan, permintaan tarik) ke Backbone merusak kompatibilitas mundur dalam beberapa cara kecil ... bahkan jika hanya untuk orang-orang yang mengandalkan perilaku yang sebelumnya tidak ditentukan.

Jika kita secara ketat mengikuti versi "semantik", mungkin sekarang Backbone.js 43.0.0 — yang tidak membantu siapa pun mengevaluasi kemajuan proyek yang sebenarnya.

Jadi, karena saya suka bercanda — bukan versi "semantik", _versi romantis_.

Diberikan nomor versi MAJOR.MINOR.PATCH, tambahkan:

Versi UTAMA saat Anda membuat rilis baru yang besar, atau memperbarui dan/atau menstabilkan API secara signifikan.
Versi MINOR saat Anda menambahkan fitur baru kecil.
Versi PATCH ketika Anda membuat perubahan kecil, kemungkinan besar tidak diperhatikan oleh sebagian besar orang.

Ini memungkinkan orang, segera setelah mendengar tentang rilis baru, untuk mendapatkan gambaran kasar tentang cakupannya. Mengenai kompatibilitas mundur — idealnya _setiap_ rilis, bahkan yang besar, kompatibel dengan versi sebelumnya. Dan ketika tidak bisa, karena API berubah, itu harus dilakukan dengan cara yang tidak terlalu sulit untuk ditingkatkan.

Tetapi menghindari perubahan apa pun pada API, dan menunggu rilis "UTAMA" siap akan menjadi hambatan besar untuk kemajuan. Dan alternatif untuk sering menambah nomor versi UTAMA sangat tidak membantu.

Sejujurnya, saya lebih suka skema yang lebih sederhana yang hanya menggunakan nomor versi BIG.SMALL — seperti kebanyakan aplikasi desktop ... tapi saya khawatir akan merusak pengelola paket dan perkakas lainnya.

Apa masalahnya dengan berada di Backbone 43.0.0?

• Dikirim dari Chrome 32.0.1700

+1 untuk spadgos@ pertanyaan. Nomor versi bersifat arbitrer. Untuk beberapa alasan, kami memiliki aplikasi web gesit yang mencoba untuk tetap berada dalam rentang yang sama dengan OS. Banyak aplikasi panik karena melewati 10...tetapi sebagian besar proyek yang Anda modelkan (Windows, Linux, dll) memiliki siklus dev 1 tahun/multi-tahun sebelum rilis, jadi 1.x -> 2.x adalah masalah besar. Proyek tangkas bergerak sangat cepat, bertambah dengan cepat juga masuk akal.

Saya juga tidak setuju dengan alasan di balik ini.

Marionette ada di v1.2.3 sekarang, dan melakukan yang terbaik untuk mengikuti versi semantik yang ketat. Sejauh ini, kami tidak memiliki masalah apa pun meskipun kami "semua area permukaan" juga. Kami telah menambahkan fitur baru. Kami telah memperbaiki bug. Tapi v1.0 masih kompatibel dengan v1.2.3. Kami telah menangguhkan tiket untuk rilis v2 saat itu adalah API atau perubahan perilaku yang diharapkan.

Rilis besar dengan perubahan yang melanggar tidak harus terjadi setiap minggu saat pull request diterima. Ini dapat (dan harus) digabungkan ke rilis utama yang mencakup nilai yang cukup untuk rilis besar dengan versi utama bump.

Seperti berdiri, melanggar kompatibilitas dalam rilis v1.1 menyebabkan banyak rasa sakit bagi pengembang plugin dan add-on, seperti tim MarionetteJS. Kami harus mengisi ulang perilaku dengan tambalan dalam kode kami, sehingga kami dapat tetap layak untuk v1.0 dan v1.1... ini bukan situasi yang menyenangkan. Efek riak dari perpustakaan inti seperti Backbone yang mengalami perubahan besar, sangat besar... bukan hanya Backbone yang terpengaruh.

Saya setuju ini sepertinya lebih seperti kasus "tidak mau" daripada "tidak bisa." Perubahan yang melanggar seperti https://github.com/jashkenas/backbone/pull/2461 tidak memiliki rasa urgensi yang nyata, dan dapat menunggu pembaruan versi utama jika Anda tidak menginginkan masalah 43.0.1.

Bagi saya, masalah terbesar dengan Backbone tidak menghormati semver (antara lain) adalah dalam mengajar dan menginjili Backbone. Tidaklah bagus untuk memberi tahu sekelompok siswa atau pelanggan potensial bahwa semua yang ada di tumpukan Anda akan bekerja dengan cara tertentu... kecuali untuk Backbone.

Selalu ada dua peringatan besar ketika "menginjili" Backbone: itu bukan AMD di luar kotak, dan itu tidak menghormati SemVer, jadi jangan menganggap serius nomor versi. Salah satunya adalah tetap. Mari kita perbaiki yang lain.

Sejujurnya, saya lebih suka skema yang lebih sederhana yang hanya menggunakan nomor versi BIG.SMALL — seperti kebanyakan aplikasi desktop ... tapi saya khawatir akan merusak manajer paket dan alat lainnya.

@jashkenas kita selalu bisa meninggalkan angka ke-3 di .0 :)

Itu mungkin akan memetakan secara semantik ke SemVer sedikit lebih dekat daripada yang kami lakukan sekarang. Mungkin itu akan mengurangi beberapa sniping kripto-politik pasif-agresif tentang bagaimana secara teknis salah untuk tidak mengikuti SemVer.

Saya pikir poin Bob benar karena lebih penting untuk secara jelas mengartikulasikan sistem apa yang kita ikuti, terlepas dari sistem apa yang kita ikuti.

ps Saya tidak bermaksud menyiratkan bahwa masalah @keithamus adalah pasif agresif dan saya minta maaf jika itu terjadi. Jelas sah untuk membahas bagaimana Backbone mengomunikasikan perubahan kepada pengguna.

:+1: untuk semver. Saya terutama tertarik pada versi perangkat lunak tertentu bukan sebagai indeks kemajuannya tetapi kompatibilitasnya.

Secara umum, setelah 1.0 (ketika saya berharap sebagian besar stabil dan berfungsi), nomor versi sebagian besar tidak berarti sebagai indikator kemajuan. Software X pada versi 10 mungkin jauh kurang matang, memiliki fitur yang lebih sedikit dibandingkan Software Y pada versi 2. Jika Anda ingin mengetahui perkembangan sebuah software, Anda harus melihat changelog atau roadmapnya.

Mengetahui bahwa Backbone (atau apa pun) ada di 2.4.3 tidak berarti apa-apa dalam hal fitur-fiturnya. Ini _should_, bagaimanapun, berarti bahwa saya dapat meng-upgrade dari 2.0.4 saya tanpa melanggar apapun.

Jika kita secara ketat mengikuti versi "semantik", mungkin sekarang Backbone.js 43.0.0 — yang tidak membantu siapa pun mengevaluasi kemajuan proyek yang sebenarnya.

Masalah yang sangat kecil / mungkin tidak ada. Tidak mengikuti semver? Masalah besar.

:+1:, semver harus dimiliki untuk proyek sebesar itu.

Saya bersama @knowtheory. 43.0.0 terlihat agak aneh tapi saya pikir 1.43.0 akan baik-baik saja dan tidak ada yang akan mendapatkan kejutan kerusakan setelah npm install .

Siapa yang peduli dengan nomor versi yang tinggi?
Itu standar, jika Anda bisa menggunakannya, Anda harus menggunakannya.
Saya bahkan tidak mengerti mengapa diskusi ini berlangsung begitu lama.

:+1: Ini akan mencegah beberapa masalah di #2996 dan #2997, dan masalah lain yang dialami dengan beberapa rilis Backbone lainnya.

@braddunbar itu (dan alasan lainnya "melawan") terdengar seperti menghargai estetika nomor versi di atas makna sebenarnya.

Terima kasih, tetapi mengikuti versi "semantik" dengan ketat tidak akan berhasil dengan baik untuk Backbone.

Saya pikir ini lebih tentang Backbone yang bekerja dengan baik untuk penggunanya (dengan manajemen ketergantungan). Semver berikut mana yang akan menjamin ...

Rilis yang lebih sering akan membantu menangkap bug showstopper lebih cepat. Saya pikir terlalu banyak meminta orang untuk terus-menerus menjalankan versi Edge dari Backbone hanya untuk mendapatkan perbaikan bug yang mereka butuhkan.

+1 @derickbailey

Seperti contohnya sejak 1.1.0, ide di balik rilis patch adalah perbaikan ini tidak diperlukan sama sekali.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

Untuk paket di npm atau bower, ini bahkan tidak untuk diperdebatkan.

Saat Anda memublikasikan paket dengan npm atau bower, semver adalah bagian dari kontrak API yang Anda masuki. Saat Anda melanggar kontrak itu, Anda merusak modul lain yang bergantung pada Anda. Anda memecahkan kode produksi yang bergantung pada modul Anda.

Pertanyaannya bukan, "haruskah kita menggunakan semver?" Pertanyaannya adalah, "apakah kita ingin menjadi warga yang baik dalam ekosistem?"

Jika jawabannya tidak, itu harus diiklankan dengan keras dan jelas, karena tidak aman hanya menginstal paket Anda seperti yang Anda lakukan pada paket lain yang mengikuti kontrak API.

Saat Anda memublikasikan paket dengan npm atau bower, semver adalah bagian dari kontrak API yang Anda masuki.

Tidak. npm install --save [email protected] bukanlah persyaratan yang berat.

@ akre54 Saya tertarik dengan perspektif Anda tentang semver Saya tahu pemikiran @jashkenas tentangnya tetapi apa pendapat Anda.

@akre54 Ya, benar. npm mengasumsikan bahwa semua paket dalam repositori mengikuti semver . Begitulah cara menentukan paket mana yang kompatibel dengan yang mana.

Dari dokumen package.json :

"Versi harus dapat diuraikan oleh node-semver, yang dibundel dengan npm sebagai dependensi. (npm install semver untuk menggunakannya sendiri.)"

Jika nomor versi Anda _lie_ ketika ditafsirkan sebagai semver, itu bukan penguraian yang benar. Jadi, Anda melanggar kontrak package.json , dan Anda melanggar kompatibilitas dengan cara orang menggunakan versi paket di ekosistem npm.

Itu bukan hanya masalah preferensi pribadi. Ini masalah interoperabilitas paket.

Apakah mungkin untuk memaksa paket Anda bermain bagus jika tidak menggunakan semver? _Tentu_, memang, tetapi jika Anda tidak menyebutnya dengan keras dan berani di bagian atas readme Anda -- beberapa pengguna akan tahu bahwa itu perlu, dan ketika Anda memperkenalkan perubahan yang melanggar, kode mereka dapat dengan mudah rusak.

Setelah Anda mempublikasikan paket Anda ke repositori paket, pembuatan versi menjadi bagian dari kontrak interoperabilitas. Anda mengabaikan kontrak itu dengan risiko pengguna Anda.

npm install --save [email protected] bukanlah persyaratan yang berat.

Mengetahui mana dari ribuan paket yang masuk ke aplikasi penuh sesak, Anda harus melakukan ini dengan _adalah_ persyaratan yang berat. Memaksa pengguna untuk mengunci dengan ketat versi semua paket mereka karena beberapa modul tidak mengikuti aturan _adalah_ persyaratan yang berat, karena memperumit masalah untuk mengikuti perbaikan bug, patch keamanan, dll...

Ada alasan yang sangat bagus untuk mengikuti semver. "Nomor paket saya mungkin menjadi sangat besar" adalah alasan buruk _not_ untuk menggunakan semver. Melacak kemajuan aplikasi Anda adalah alasan kedua yang jauh untuk versi paket. Fungsi terpenting dari versi ini adalah untuk mengetahui, "apakah versi ini akan berfungsi dengan aplikasi saya?"

BTW, jika nomor paket Anda menjadi sangat besar, mungkin itu bau kode. Anda hanya perlu menabrak versi utama ketika Anda membuat _breaking change_. Perubahan yang melanggar menurut definisi adalah yang _melanggar prinsip buka/tutup_. Terbuka untuk ekstensi, ditutup untuk melanggar perubahan. Semua API yang baik mengikuti prinsip buka/tutup sedekat mungkin, sehingga pengguna dapat mengikuti API, dan perubahan tidak merusak kode yang ada.

Saya pikir pelajaran yang dipetik di sini adalah "jangan gunakan ~ atau ^ saat menarik Backbone melalui package.json"

@akre54 Saya tertarik dengan perspektif Anda tentang semver

Secara umum saya setuju dengan argumen di sini, tetapi saya harus bertanya-tanya apakah menabrak versi utama adalah tindakan terbaik pada _setiap_ perubahan yang melanggar (dan sekali lagi, dengan Garis Bawah sebagian besar merupakan area permukaan, itu _banyak_). Garis bawah digunakan di banyak perpustakaan pihak ketiga, dan mengharuskan mereka semua untuk mengikuti versi besar akan berat dan berbahaya. (Haruskah sebuah paket yang dirilis hari ini bergantung pada Garis Bawah hingga versi 2? 1.7? 1.6.x? Haruskah itu menyematkan dependensinya dengan mengorbankan mungkin memerlukan Garis Bawah yang terpisah dari proyek utama?)

Saya pikir pelajaran yang dipetik di sini adalah "jangan gunakan ~ atau ^ saat menarik Backbone melalui package.json"

ya.

Saya pikir pelajaran yang dipetik di sini adalah "jangan gunakan ~ atau ^ saat menarik Backbone melalui package.json"

Saya telah menguraikan di atas mengapa ini tidak boleh menjadi pelajaran yang bisa dibawa pulang.

Saya pikir pelajaran yang dipetik di sini adalah "jangan gunakan ~ atau ^ saat menarik Backbone melalui package.json"

Itulah yang Anda lakukan, sebagai akibatnya, untuk melindungi kode Anda agar tidak rusak.

Pelajarannya akan lebih seperti "mengikuti semver baik untuk semua orang, tidak melakukannya tidak."

Saya dapat menghargai nilai dalam versi "romantis". Sayang sekali mereka tidak hidup berdampingan dengan baik.

Perlu dicatat bahwa akan selalu ada proyek yang tidak mengikuti semver dengan sangat ketat, dan proyek yang mencoba gagal, sehingga sistem selalu sedikit bocor.

Setidaknya Backbone umumnya sangat bagus untuk tidak merusak barang.

@dgbeck hal-hal rusak sepanjang waktu per versi lihat komentar saya sebelumnya

Jadi saya pikir nilai dalam mengikuti semver yang belum terlalu dibicarakan adalah kenyataan bahwa kalian dapat mendorong fitur minor dan perbaikan bug dan memungkinkan orang yang bergantung padanya untuk mendapatkan perubahan ini secara gratis.

Bagi saya ini adalah nilai tambah yang bagus tetapi jelas ini harus dibayar dengan kerumitan bagi pengelola.