Underscore: Garis bawah tidak mengikuti SemVer

Mengutip https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

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.

Sisa komentar juga layak dibaca, bahkan jika Anda tidak setuju.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 juga

@ akre54 Saya ingin tahu apa pendapat Anda tentang kenyataan bahwa proyek lain seperti Lo-Dash (Alternatif garis bawah) dan ExosJS (alternatif Backbone) dapat mengikuti semver?

Karena penggantian drop-in itu _dapat mengikuti semver_ tidakkah hal itu menjadi alasan yang didorong oleh inti Underscore/Backbone?

Beberapa hal.

Lo-Dash, untuk sebagian besar, menempel pada jalur sapi yang diaspal oleh Underscore, sehingga memiliki keuntungan untuk menunda hingga rilis Underscore untuk mendorong versi bump untuk paritas fitur. Perbedaan dari Garis Bawah cenderung lebih pada kategori peningkatan dan lebih sedikit pada perubahan yang melanggar signifikan.

Lo-Dash menambahkan lebih banyak kode penjaga untuk bc dengan mengorbankan kekacauan kode sementara Underscore berusaha keras. Lebih mudah untuk pergi dengan beberapa baris kode tambahan ketika perpustakaan lebih besar untuk memulai (Lo-Dash jam di 8.7k baris vs 1.4k untuk Garis Bawah.) Ada juga lebih banyak pembersihan internal yang dapat dilakukan di Lo- Dash karena begitu banyak logika internal.

Itu juga ditulis secara tidak proporsional oleh satu kontributor (Anda), sedangkan perubahan Garis Bawah cenderung berasal dari kumpulan kontributor yang jauh lebih beragam, yang berarti fitur baru dapat datang kapan saja, dan terkadang perubahan fitur besar dan perubahan yang tidak kompatibel ke belakang datang pada saat yang tidak tepat untuk jadwal rilis.

Secara anekdot, saya merasa Underscore juga memiliki kelemahan jadwal rilis karena digunakan di lebih banyak proyek pemula daripada Lo-Dash (pada dasarnya, Lo-Dash cenderung menarik bagi para pengembang yang membutuhkan kekuatannya). Pengembang yang lebih maju akan lebih nyaman menangani dampak dari melanggar perubahan, dan mungkin lebih memahami alasan mereka.

Terakhir, sebagai penulis bersama dan kontributor utama Exoskeleton, saya akan menjadi orang pertama yang memberi tahu Anda bahwa kami juga belum mengikuti semver. Kami juga memiliki kelebihan Lo-Dash seperti yang dijelaskan di atas.

Lo-Dash, untuk sebagian besar, menempel pada jalur sapi yang diaspal oleh Underscore, sehingga memiliki keuntungan untuk menunda hingga rilis Underscore untuk mendorong versi bump untuk paritas fitur. Perbedaan dari Garis Bawah cenderung lebih pada kategori peningkatan dan lebih sedikit pada perubahan yang melanggar signifikan.

Apa hubungannya dengan strategi versi Underscore? Lo-Dash menabrak versi setelah semver itulah sebabnya di v2.x terjadi di v3.x.

Lo-Dash menambahkan lebih banyak kode penjaga untuk bc dengan mengorbankan kekacauan kode sementara Underscore berusaha keras.

Apa hubungannya kode penjaga atau singkat dengan strategi versi?

Lebih mudah untuk pergi dengan beberapa baris kode tambahan ketika perpustakaan lebih besar untuk memulai (Lo-Dash masuk pada 8.7k baris vs 1,4k untuk Garis Bawah.)

Lo-Dash memiliki dokumen sebaris, LOC tidak relevan dengan pembuatan versi.

Ada juga lebih banyak penyelewengan internal yang dapat dilakukan di Lo-Dash karena begitu banyak logika internal.

Tidak bisakah hal yang sama dikatakan untuk Garis Bawah?

Itu juga ditulis secara tidak proporsional oleh satu kontributor (Anda), sedangkan perubahan Garis Bawah cenderung berasal dari kumpulan kontributor yang jauh lebih beragam, yang berarti fitur baru dapat datang kapan saja, dan terkadang perubahan fitur besar dan perubahan yang tidak kompatibel ke belakang datang pada saat yang tidak tepat untuk jadwal rilis.

Itu sebabnya Underscore memiliki pengelola untuk menerima/menolak atau mendorong hingga rilis mendatang.
Sekali lagi, tidak relevan dengan pembuatan versi.

Secara anekdot, saya merasa Underscore juga memiliki kelemahan karena digunakan di lebih banyak proyek pemula daripada Lo-Dash (pada dasarnya, Lo-Dash cenderung menarik bagi para pengembang yang membutuhkan kekuatannya).

Saya tidak setuju, Lo-Dash memiliki ribuan tanggungan dan semua tidak bisa menjadi ahli dengan itu.

Pengembang yang lebih maju akan lebih nyaman menangani dampak dari melanggar perubahan, dan mungkin lebih memahami alasan mereka.

Karena Lo-Dash mengikuti semver devs tidak harus berurusan dengan kejatuhan sampai mereka melompat ke pembaruan versi utama. Tidak seperti Underscore, Lo-Dash tidak akan berubah karena mereka menggunakan ~ untuk rentang versi paket.

Terakhir, sebagai penulis bersama dan kontributor utama Exoskeleton, saya akan menjadi orang pertama yang memberi tahu Anda bahwa kami juga belum mengikuti semver.

Maka Anda harus menghapusnya dari pemasarannya.

Saya tidak berpikir ada alasan mengapa Garis Bawah tidak bisa mengikuti semver.
Tidak mengikuti itu merugikan pengguna Anda : mengerutkan kening:

Jika Anda ingin dimasukkan dalam npm atau bower, itu bukan untuk diperdebatkan. Anda harus menggunakan semver. Anda membuat janji implisit untuk mengikuti semver, dan jika tidak, itu merusak kode orang tanpa peringatan, dan itu tidak disukai oleh hampir semua orang.

Kita berbicara tentang pilihan yang melanggar kode produksi. Tidak keren memainkan permainan ceroboh dengan waktu dan uang orang lain.

Itu berarti nomor versi Anda menjadi lebih besar lebih cepat. Terus? Ini nomor. Itu jauh lebih baik daripada merusak keranjang belanja produksi seseorang.

+1 untuk semver

Secara pribadi, saya tidak berpikir itu "keren" untuk mendapatkan _personal_ dalam laporan bug. Entah itu atau tidak mengikuti versi semantik. Inilah alasannya--bang, bang, bang--mengapa perpustakaan ini akan menjadi lebih baik jika memang demikian. Berikut adalah alasannya--bang, bang--mengapa layak bagi pengelola untuk menambah nomor versi dengan cara yang sesuai dengan semver.

Setelah itu, terserah pengelola. Jika Anda tidak setuju dengan pendirian mereka, ada perpustakaan alternatif untuk digunakan.. Anda dapat melakukan fork proyek (seperti yang dilakukan orang lain). Anda dapat menulis posting blog secara pribadi sesuka Anda.

Tapi mari kita coba untuk memiliki perselisihan sipil.

Saya tidak mengerti @raganwald. Siapa yang menjadi pribadi?

Saya tidak menyerang siapa pun. Saya menunjukkan bahwa semver adalah bagian dari kontrak API yang Anda masuki ketika Anda menerbitkan paket ke npm atau bower.

Jika Anda melanggar kontrak itu, Anda melanggar kode orang lain. Itu tidak keren.

npm bekerja dengan sangat baik karena kita semua menyetujui beberapa aturan yang membuat modul kita bekerja dengan baik satu sama lain. Jika Anda melanggar aturan itu, Anda melanggar modul lain yang mencoba bekerja dengan Anda. Anda merusak aplikasi produksi yang mengandalkan kode Anda.

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

Poin kuncinya adalah bahwa pada proyek seperti Garis Bawah, _setiap_ perubahan melanggar seseorang. Jika kita menghapus null guard dari _.extend (untuk menggunakan contoh acak) karena menyebabkan bug untuk seseorang, dan membuat bug untuk orang lain, apakah itu patch? Apakah itu versi minor? Besar?

Untuk Garis Bawah dan Tulang Belakang, saya rasa tidak masuk akal untuk menyematkan dependensi Anda. Mengikuti semver bukanlah persyaratan untuk memublikasikan ke pembuat paket.

Poin kuncinya adalah bahwa pada proyek seperti Garis Bawah, setiap perubahan merugikan seseorang.

Anda melompat ke ekstrem untuk membenarkan posisi Anda. Kenyataannya adalah keseimbangan. Ada API populer, kasus tepi, dan perilaku yang terdokumentasi. Sangat mungkin untuk pergi untuk waktu yang lama tanpa menabrak versi utama hanya dengan memperbaiki bug dan menambahkan fungsionalitas.

Artinya, pengelola harus berpikir dan merencanakan. Ini berarti Anda mungkin harus membuat peta jalan untuk fitur atau perubahan yang tidak dapat ditangani tanpa melanggar back-compat dan itu tidak masalah.

Garis bawah telah menabrak rilis tambalan dan memperkenalkan perubahan besar. Ini adalah sesuatu yang benar-benar dapat dikendalikan oleh pengelola.

Untuk Garis Bawah dan Tulang Belakang, saya rasa tidak masuk akal untuk menyematkan dependensi Anda.

Pasti ada pesan/peringatan dalam dokumentasi.

@akre54 Mengubah fitur _undocumented_ atau _undocumented bugs_ dapat merusak kode yang bergantung pada fitur tersebut, tetapi pengguna bergantung pada fitur dan bug yang tidak terdokumentasi dengan risiko mereka sendiri.

Mengabaikan semver menempatkan _setiap pengguna_ API Anda dalam bahaya. Orang-orang memperbaiki bug di proyek open source besar yang mengikuti semver sepanjang waktu, tetapi _sangat jarang melihat nomor versi besar di ekosistem npm_.

Mengapa demikian?

Karena _semua API yang baik mengikuti prinsip buka/tutup_ (buka untuk ekstensi, tutup untuk menghentikan perubahan) sedekat mungkin, sehingga pengguna dapat mengikuti API, dan perubahan tidak merusak kode yang ada.

Untuk menambah anekdot, kode saya juga telah rusak oleh garis bawah benjolan di masa lalu. Kami terpaksa melakukan node_modules untuk mencegahnya karena --save --save-exact tidak memotongnya. Jika ketergantungan tingkat kedua bergantung pada Garis Bawah dan menggunakan versi ^x.y.z maka aplikasi Anda masih rusak.

Adapun nomor versi yang menunjukkan kemajuan, saya tidak peduli. Menggunakan versi 2.1.3 atau 143.3.2 tidak ada bedanya bagi saya. Kemajuan dan kedewasaan perpustakaan tidak diukur dalam nomor versi. Saya hanya tidak ingin panggilan telepon pada hari Minggu sore karena seseorang memperbarui ketergantungan yang bergantung pada underscore@^x.y.z .

:jempol: iya. @braddunbar membuat poin yang belum saya jelaskan -- mengabaikan semver membuat paket Anda menjadi paket yang berbahaya dan ganas, karena perubahan yang melanggar itu bisa bertahan _anywhere_.

Ini _pasti merupakan persyaratan yang berat_ untuk memaksa pengguna mencari jeda dalam kode pihak ketiga yang bergantung pada paket Anda yang rusak.

IMO, kemajuan dan kedewasaan perpustakaan yang sebenarnya diukur dalam ketergantungan, dan semver berjalan jauh untuk mencapai tujuan itu.

Pasti ada pesan dalam dokumentasi.

Pastinya. Saya senang menambahkan satu jika itu yang kami putuskan.

Saya tidak menentang sistem rilis yang lebih baik (tuan tahu itu menyakitkan untuk menunggu berbulan-bulan untuk satu perbaikan bug kecil Anda untuk digunakan), tapi saya tidak yakin "ikuti semver" adalah _the_ satu jawaban yang benar.

Saat ini, saya tidak berpikir itu penting jika itu satu-satunya jawaban yang benar. Ini _is_ komunitas menerima jawaban.

Saya tidak berpikir ada yang mengatakan "ikuti semver" adalah satu-satunya jawaban yang tepat untuk sistem rilis yang lebih baik. Apa yang kami katakan adalah bahwa itu adalah kontrak API npm, dan melanggar kontrak itu akan merusak.

@jdalton dan @dilvie Bagaimana Anda mengusulkan kami menangani rilis? Bagaimana dengan menerima fitur? "Gunakan semver" tidak benar-benar memberi tahu kita apa pun.

Haruskah kita mendorong kembali fitur seperti _.matches beberapa bulan sehingga kita dapat menunggu perbaikan bug untuk kode saat ini, atau haruskah kita merilisnya sekarang dan membiarkan orang menyelesaikan masalah implementasi?

Saya pikir semver tidak sepenuhnya berlaku di sini.

Promosi diri yang tidak tahu malu: gunakan pembaruan berikutnya https://github.com/bahmutov/next-update untuk menguji terlebih dahulu apakah dependensi dapat diperbarui tanpa merusak proyek Anda. Saya terus-menerus menemukan perubahan yang melanggar dalam modul yang berbeda meskipun diubah *.*.x , jadi sekarang saya tidak mempercayai versi yang dideklarasikan sendiri.

Apakah Anda pikir proyek ini adalah kepingan salju? Lo-Dash pada dasarnya adalah Garis Bawah ++, dan mengikuti semver tidak masalah untuk @jdalton.

Menerima fitur baru:

Apakah itu melanggar kontrak API yang ada?

Ya? - menabrak nomor versi utama.
Tidak? - menabrak nomor versi minor.

Menerima perbaikan bug/tambalan kecil:

Apakah itu melanggar kontrak API yang ada?

Ya? - menabrak nomor versi utama.
Tidak? - nomor versi tambalan benjolan.

Bagaimana Anda memilih untuk menjadwalkan rilis resmi sepenuhnya terserah Anda. Pastikan versinya kompatibel dengan semver sehingga Anda tidak merusak kode orang lain.

Setuju dengan @dilvie , misalnya https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 mungkin seharusnya menjadi masalah besar karena kami menjatuhkan dukungan untuk sparse array. Versi berikutnya akan menjadi terobosan besar karena kami akan menambahkan satu ton gula baru melalui lookupIterator dan menghapus iterator asli.

Jika dokumentasi suatu fungsi harus diubah, itu jelas merupakan perubahan besar

Saya melakukan diskusi singkat tentang ini di JSconf tahun ini. Saya tidak punya waktu untuk menjelaskan secara rinci, di sini, tetapi:

berhenti menggabungkan "versi" yang menghadap manusia dengan "kompatibilitas API" yang menghadap komputer (atau benar-benar, menghadap ke sistem). berhenti saja.

Versi: "Hal yang saya suka ini memiliki fitur baru, atau sesuatu yang lain yang harus saya minati ketika saya punya waktu." Ada iPhone baru. Ada OS X baru. Ada Ember baru. Ada Laporan Revisi baru tentang Skema Bahasa Algoritma.

Kompatibilitas API: “Hal ini telah diperbarui untuk diperbaikimasalah, dan ini mungkin/akan memecahkan jalanmelatih hal itu.” Steker listrik iPhone diganti. garpu sumber daya OS X tidak digunakan lagi. Ember tidak lagi menggunakan gaya nama tindakan. Skema sekarang peka huruf besar-kecil.

Yang terakhir terjadi _selama_, atau _sepanjang_, yang pertama; tetapi yang pertama sama sekali tidak bergantung pada, atau bahkan terkait dengan, yang terakhir. Mereka harus dilacak, dan (jika kita benar-benar akan _menentukan_ sistem versi, yesus) ditentukan, secara terpisah. (konsep 'versi semantik' yang populer di komunitas JS adalah _khususnya_ tumpul dan mengerikan; tetapi sekali lagi, bukan sesuatu yang ingin saya bahas secara rinci di utas komentar Masalah orang lain.)

tl;dr: Mereka tidak mengacaukan ekosistem Anda dengan memilih jalur mereka sendiri. (_Terutama_ ketika jalan itu sangat cacat.) Saya berharap lebih banyak proyek akan melakukannya. Pergi menggunakan sesuatu yang lain, jika Anda yang membungkuk keluar dari bentuk di atasnya.

@elliottcable - setuju tentang menghadap manusia vs menghadap komputer ... Selama menghadap manusia tidak terlihat seperti menghadap komputer sehingga conflating kurang bermasalah.

Mungkin memanggil manusia berikutnya yang menghadap rilis sesuatu seperti "kepingan salju" bukan nnn

Benar-benar tidak setuju dengan bit terakhir, meskipun. Saat Anda berpura-pura mengikuti kontrak API dan kemudian melanggarnya, hal-hal akan rusak. Biayanya orang lain waktu nyata dan uang nyata. Dengan proyek sepopuler garis bawah, ada potensi banyak kerusakan nyata yang terjadi.

Apakah itu melanggar kontrak API yang ada?

Lihat kembali argumen pertama di utas ini. "Semua yang ada di Underscore pada dasarnya adalah area permukaan", ergo, semuanya, didokumentasikan dan tidak, adalah bagian dari kontrak API-nya. Setiap perubahan adalah perubahan untuk semua orang.

Lo-Dash, menjadi "Underscore++" tidak menangani banyak perubahan fitur karena dapat mengikuti dengan aman di belakang Garis Bawah dalam mengerjakan fitur-fitur utama. Peningkatan Lo-Dash terutama di bawah tenda atau dalam menambahkan beberapa metode, tidak secara mendasar memikirkan kembali fitur-fiturnya.

@akre54

Bagaimana Anda mengusulkan kami menangani rilis? Bagaimana dengan menerima fitur? "Gunakan semver" tidak benar-benar memberi tahu kita apa pun.

Anda dapat menerima API baru atau bahkan beberapa peningkatan pada API yang sudah ada. Jika Anda menambahkan API atau peningkatan baru (yang tidak merusak kompatibilitas), ini adalah pembaruan versi kecil.

Haruskah kita mendorong kembali fitur seperti _.matches beberapa bulan sehingga kita dapat menunggu perbaikan bug untuk kode saat ini, atau haruskah kita merilisnya sekarang dan membiarkan orang menyelesaikan masalah implementasi?

Saya pikir _.matches cukup mudah. Akan selalu ada perbaikan bug.

Saya pikir semver tidak sepenuhnya berlaku di sini.

Tentu saja. Anda mulai masuk ke masalah siklus rilis, yang terpisah dari semver, tapi saya akan mengikuti Anda di sana.

@dilvie : akan menghindari sisa argumen, tetapi melemparkan ini: sangat, sangat menyukai saran Anda untuk mengikuti konvensi 'nama versi'. (=

Untuk bagian yang menghadap manusia, saya penggemar berat less -style versioning:

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

… gabungkan itu dengan nama yang cantik, untuk membuatnya lebih jelas bahwa kita berbicara tentang "ketertarikan" -versi, bukan kompatibilitas API, dan Anda memiliki kombo yang unggul.

+1 untuk Garis Bawah 42: "Sheltie Konyol."

(Mengenai bagian yang menghadap sistem build, saya memiliki beberapa pandangan kontroversial tentang kompatibilitas API generatif otomatis. Mari kita singkirkan ini dari tangan pengelola yang salah, dan serang dengan analisis statis atau perayapan dinamis.)

@akre54

Lo-Dash, menjadi "Underscore++" tidak menangani banyak perubahan fitur karena dapat mengikuti dengan aman di belakang Garis Bawah dalam mengerjakan fitur-fitur utama.

Apa artinya itu? Lo-Dash menangani _lebih banyak perubahan_ dan mengikuti versinya sendiri yang terpisah dari Garis Bawah. Lo-Dash telah banyak berubah sehingga harus menawarkan build Underscore-compat untuk melanjutkan dukungannya sebagai pengganti drop-in. Kami memiliki fitur , metode, dan masalah kompatibilitas API yang berbeda.

Peningkatan Lo-Dash terutama di bawah tenda atau dalam menambahkan beberapa metode, tidak secara mendasar memikirkan kembali fitur-fiturnya.

Bukan itu masalahnya. Lo-Dash bergerak lebih cepat dan lebih sering berlari melawan back compat. Inilah mengapa kami ~v2.x melanjutkan ~v3.x. Lo-Dash mirip dengan Garis Bawah. Jika Lo-Dash dapat mengikuti semver maka dapat Menggarisbawahi. Saya sudah melakukannya selama ~ 2 tahun sekarang. Argumen Anda hanya jatuh datar di hadapan kenyataan.

Saya pernah melalui jalan ini sebelumnya sehingga saya dapat membantu Anda semua sampai di sana juga.
Sebagai permulaan, rilis Underscore berikutnya akan menjadi 2.0 yang hebat.

Saya ingin tahu bagaimana semua orang berpikir "melanggar perubahan" harus didefinisikan. _Setiap_ perubahan fitur baru ke Garis Bawah adalah perubahan besar bagi orang lain.

Mari kita ambil contoh semua perubahan terbaru pada _.each . Haruskah kami bertemu ketika kami mengubah nilai pengembalian _.each untuk mengembalikan daftar asli ? Apakah ini perbaikan bug? Sebuah fitur baru? Perubahan yang tidak kompatibel ke belakang? Itu mengembalikan undefined sebelumnya, jadi tidak mungkin itu merusak kode siapa pun.

Haruskah kita bertemu ketika kita mengizinkan internal each helper ditugaskan kembali secara eksternal ? Mungkinkah itu telah memecahkan kode seseorang? Tidak ada API publik yang berubah di sana.

Mengubah _.each untuk menghindari sparse arrays dan menggunakan for loop sebagai ganti native forEach jelas melanggar untuk beberapa orang, tetapi karena sparse arrays sudah mati, siapa yang peduli? Apakah itu sesuatu yang harus kita dorong ke versi utama? Apakah ini perbaikan bug?

Saya pikir kita terlambat pada versi utama (banyak yang telah terjadi di 219 commit ). Rilis 2.0 dan pemadatan kebijakan versi kami akan sangat membantu di sini.

@akre54

Setiap perubahan fitur baru ke Garis Bawah adalah perubahan besar bagi orang lain.

Belum tentu.

Mari kita ambil contoh semua perubahan terbaru pada _.each. Haruskah kita bertemu ketika kita mengubah nilai kembalian _.each untuk mengembalikan daftar asli? Apakah ini perbaikan bug?

Ini bukan perbaikan bug, ini peningkatan. Apakah ini tidak melanggar?-- Ini mungkin perubahan yang aman karena tidak mungkin nilai pengembalian _.each dapat diandalkan dan bukan sesuatu yang dilaporkan oleh pengembang sebagai penghalang jalan saat beralih ke Lo-Dash. Jika ragu sisi dengan melanggar, atau uji air dengan rilis RC. Jika perubahan itu memungkinkan keluar lebih awal dari _.each Saya akan mengatakan itu adalah perubahan yang pasti karena devs mengalaminya saat menggunakan CoffeeScript.

Haruskah kita bertemu ketika kita mengizinkan internal setiap pembantu untuk ditugaskan kembali secara eksternal? Mungkinkah itu telah memecahkan kode seseorang? Tidak ada API publik yang berubah di sana.

Saya akan mengatakan bahwa itu termasuk dalam detail implementasi yang tidak berdokumen. Pada saat itu perubahan tidak mengizinkan sesuatu yang baru karena Garis Bawah masih bercabang untuk metode asli. Perubahan ini termasuk dalam kelompok perubahan yang lebih besar di pos 1.6.0 sehingga bisa mendarat di 2.0.

Mengubah _.each untuk menghindari sparse arrays dan menggunakan for loops daripada native forEach jelas melanggar untuk beberapa orang, tetapi karena sparse arrays sudah mati, siapa yang peduli? Apakah itu sesuatu yang harus kita dorong ke versi utama? Apakah ini perbaikan bug?

Ini dapat dilihat sebagai perbaikan bug tetapi jelas merupakan perubahan yang melanggar. Ini adalah salah satu hal yang dialami pengembang ketika mereka beralih ke Lo-Dash. Karena bagaimana Garis Bawah dulu, menggunakan asli bila tersedia, itu akan menutupi penggunaan array yang jarang dan pengembang hanya akan menghadapi masalah jika mereka menguji di browser yang lebih lama. Namun dengan perubahan ini, para pengembang akan diperingatkan tentang penggunaan sparse array mereka lebih cepat, di browser modern, jadi ada kemungkinan kode mereka yang berfungsi sebelumnya akan mengalami hambatan.

Saya pikir kita terlambat pada versi utama (banyak yang telah terjadi di 219 komit). Rilis 2.0 dan pemadatan kebijakan versi kami akan sangat membantu di sini.

:+1:

perubahan putus (breaking change jamak)

(Komputasi) Sebuah perubahan dalam satu bagian dari sistem perangkat lunak yang berpotensi menyebabkan komponen lain gagal; paling sering terjadi di pustaka kode bersama yang digunakan oleh banyak aplikasi
"Tidak mungkin untuk memperbaiki entri lama tanpa mengubah perubahan, jadi petakan ulang yang lama ke yang baru di lib impor."

Beberapa di antaranya membutuhkan pemikiran dan penilaian. Mungkin benar bahwa semua perubahan melanggar kode seseorang, tetapi jika semua peserta setuju untuk menggunakan prinsip buka/tutup sebagai panduan untuk apa yang merupakan pelanggaran, itu membuat hidup semua orang lebih mudah.

Jadi, menambahkan properti atau metode apa pun ke API umumnya bukanlah perubahan yang merusak (API terbuka untuk ekstensi, tetapi tertutup untuk perubahan yang tidak kompatibel).

Perubahan pada tanda tangan fungsi membutuhkan lebih banyak pemikiran.

Haruskah kita bertemu ketika kita mengubah nilai kembalian _.each untuk mengembalikan daftar asli?

Apakah itu fitur API yang terdokumentasi yang memiliki tujuan tertentu? Misalnya, beberapa fungsi kembali tidak terdefinisi ketika input yang diteruskan tidak akan menghasilkan output yang masuk akal. Tampaknya tidak demikian dengan each ... Jadi, mungkin tidak melanggar.

Menghindari array jarang di sisi lain memiliki potensi yang lebih besar untuk mengubah nilai pengembalian yang diandalkan oleh pengembang, jadi jelas, itu adalah perubahan yang melanggar, dan siapa pun yang menggunakan array jarang peduli.

Array yang jarang mungkin tidak bertahan dari ES6, tetapi mereka belum mati.

@akre54
Terkadang jawaban apakah suatu perubahan melanggar atau tidak tidak langsung. Dalam kasus tersebut, konteks, riwayat, dan data membantu. Beruntung saya dapat menggunakan Lo-Dash sebagai tempat pengujian untuk fitur-fitur baru dan melihat perubahan mana yang mendorong pengembang yang berasal dari Garis Bawah. Garis bawah pada gilirannya dapat menggunakannya untuk membantu membuat keputusan berdasarkan informasi tentang dampak perubahan.

Paling tidak_ semver berikut akan membantu mencegah perubahan besar yang melanggar agar tidak masuk ke rilis patch dan mendorong pengembang untuk memikirkan dampak dari perubahan mereka. Itu adalah kemenangan untuk semua orang.

@jdalton , tindakan kelas. :)