Underscore: الشرطة السفلية لا تتبع SemVer

للاقتباس https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

شكرًا ، ولكن اتباع الإصدار "الدلالي" بدقة لن يعمل جيدًا مع Backbone. نظرًا لأن المشروع عبارة عن مساحة سطحية بالكامل تقريبًا ، وقليل جدًا من العناصر الداخلية ، فإن أي تغيير معين تقريبًا (طلب التصحيح ، طلب السحب) إلى العمود الفقري يكسر التوافق مع الإصدارات السابقة بطريقة صغيرة ... حتى لو كان ذلك بالنسبة للأشخاص الذين يعتمدون فقط على سلوك غير محدد سابقًا.

يستحق باقي التعليق القراءة أيضًا ، حتى إذا كنت لا توافق على ذلك.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 أيضًا

@ akre54 أشعر بالفضول ما هي أفكارك حول حقيقة أن مشاريع أخرى مثل Lo-Dash (بديل Underscore) و ExosJS (بديل العمود الفقري) يمكن أن تتبع semver؟

نظرًا لأن هذه البدائل المتدفقة _ يمكن أن تتبع semver_ ، أليس هذا النوع من إلقاء مفتاح ربط في العذر الذي يدفعه Underscore / Backbone core؟

أشياء زوجين.

تتمسك Lo-Dash ، في معظمها ، بممرات رعاة البقر التي تم رصفها بواسطة Underscore ، لذا فهي تتمتع بميزة التأجيل حتى إصدار Underscore لدفع إصدار عثرة من أجل تكافؤ الميزات. تميل الاختلافات من التسطير السفلي إلى أن تكون أكثر في فئة التحسينات وأقل في التغييرات الفاصلة المهمة.

يضيف Lo-Dash المزيد من كود الحماية لـ bc على حساب فوضى التعليمات البرمجية بينما تسعى Underscore جاهدة من أجل الإختصار. من الأسهل الابتعاد عن بضعة أسطر من التعليمات البرمجية الإضافية عندما تكون المكتبة أكبر لتبدأ بها (ساعات Lo-Dash في 8.7 ألف سطر مقابل 1.4 كيلو بايت للخط السفلي.) هناك أيضًا الكثير من التجريف الداخلي الذي يمكن القيام به في Lo- اندفاعة لأن الكثير من المنطق داخلي.

تمت كتابته أيضًا بشكل غير متناسب من قِبل مساهم واحد (أنت) ، بينما تميل تغييرات Underscore إلى أن تأتي من مجموعة أكثر تنوعًا من المساهمين ، مما يعني أن الميزات الجديدة يمكن أن تأتي في أي وقت ، وفي بعض الأحيان تأتي التغييرات الكبيرة في الميزات والتغييرات غير المتوافقة مع الإصدارات السابقة في لحظات غير مناسبة جدول الافراج.

من خلال القصص المتناقلة ، شعرت أن Underscore لديها أيضًا عيب جدول الإصدار المتمثل في استخدامها في العديد من المشاريع المبتدئة أكثر من Lo-Dash (بحكم طبيعتها ، تميل Lo-Dash إلى جذب المطورين الذين يحتاجون إلى قوتها). سيكون المطور الأكثر تقدمًا أكثر راحة في التعامل مع تداعيات كسر التغييرات ، وقد يفهم أسبابهم أكثر قليلاً.

أخيرًا ، بصفتي المؤلف المشارك والمساهم الرئيسي في Exoskeleton ، سأكون أول من أخبرك أننا لم نتبع semver أيضًا. لدينا أيضًا مزايا Lo-Dash كما هو موضح أعلاه.

تتمسك Lo-Dash ، في معظمها ، بممرات رعاة البقر التي تم رصفها بواسطة Underscore ، لذا فهي تتمتع بميزة التأجيل حتى إصدار Underscore لدفع إصدار عثرة من أجل تكافؤ الميزات. تميل الاختلافات من التسطير السفلي إلى أن تكون أكثر في فئة التحسينات وأقل في التغييرات الفاصلة المهمة.

ما علاقة ذلك بإستراتيجية إصدار Underscore؟ Lo-Dash تتعارض مع الإصدارات التالية لـ semver وهذا هو السبب في أنها v2.x مستمرة في الإصدار v3.x.

يضيف Lo-Dash المزيد من كود الحماية لـ bc على حساب فوضى التعليمات البرمجية بينما تسعى Underscore جاهدة من أجل الإختصار.

ما علاقة كود الحراسة أو الإيجاز باستراتيجية الإصدار؟

من الأسهل التخلص من بضعة أسطر من التعليمات البرمجية الإضافية عندما تكون المكتبة أكبر لتبدأ بها (ساعات Lo-Dash في 8.7 ألف سطر مقابل 1.4 كيلو للعلامة السفلية.)

يحتوي Lo-Dash على مستندات مضمنة ، ولا يرتبط LOC بتعيين الإصدار.

هناك أيضًا الكثير من عمليات التجريف الداخلي التي يمكن إجراؤها في Lo-Dash نظرًا لأن الكثير من المنطق داخلي.

لا يمكن أن يقال الشيء نفسه عن Underscore؟

تمت كتابته أيضًا بشكل غير متناسب من قِبل مساهم واحد (أنت) ، بينما تميل تغييرات Underscore إلى أن تأتي من مجموعة أكثر تنوعًا من المساهمين ، مما يعني أن الميزات الجديدة يمكن أن تأتي في أي وقت ، وفي بعض الأحيان تأتي التغييرات الكبيرة في الميزات والتغييرات غير المتوافقة مع الإصدارات السابقة في لحظات غير مناسبة جدول الافراج.

لهذا السبب يوجد لدى Underscore مشرفون لقبول / رفض أو تأجيل الإصدار حتى إصدار مستقبلي.
مرة أخرى ، ليست ذات صلة بالإصدار.

من خلال القصص المتناقلة ، شعرت أن Underscore أيضًا لها عيب يتمثل في استخدامها في العديد من المشاريع المبتدئة أكثر من Lo-Dash (بحكم طبيعتها ، تميل Lo-Dash إلى جذب المطورين الذين يحتاجون إلى قوتها).

لا أوافق ، Lo-Dash لديها الآلاف من المعالين وكلهم لا يمكن أن يكونوا خبراء في ذلك.

سيكون المطور الأكثر تقدمًا أكثر راحة في التعامل مع تداعيات كسر التغييرات ، وقد يفهم أسبابهم أكثر قليلاً.

نظرًا لأن Lo-Dash يتبع semver ، فلا يتعين على مطوري semver التعامل مع التداعيات حتى يقفزوا إلى تحديث إصدار رئيسي. على عكس Underscore ، لن يتغير Lo-Dash من تحت أقدامهم لأنهم استخدموا ~ لنطاق إصدار الحزمة.

أخيرًا ، بصفتي المؤلف المشارك والمساهم الرئيسي في Exoskeleton ، سأكون أول من أخبرك أننا لم نتبع semver أيضًا.

ثم يجب عليك إزالة ذلك من تسويقها.

لا أعتقد أن هناك أي سبب لعدم تمكن Underscore من متابعة semver.
عدم اتباع ذلك يعد ضررًا للمستخدمين:

إذا كنت تريد أن يتم تضمينك في npm أو bower ، فهذا ليس للنقاش. يجب عليك استخدام semver. أنت تقدم وعدًا ضمنيًا باتباع semver ، وإذا لم تفعل ذلك ، فإن هذا يكسر رمز الأشخاص دون سابق إنذار ، وهذا أمر يثير استياء الجميع.

نحن نتحدث عن خيار يكسر كود الإنتاج. ليس من الرائع أن تلعب لعبة قذرة بوقت ومال الآخرين.

هذا يعني أن أرقام الإصدارات الخاصة بك تكبر بشكل أسرع. وماذا في ذلك؟ إنه رقم. هذا أفضل بكثير من كسر عربة تسوق إنتاج شخص ما.

+1 لـ semver

أنا شخصياً لا أعتقد أنه من "الرائع" الحصول على _شخصي_ في تقرير خطأ. إما أنها تفعل ذلك أو لا تتبع الإصدارات الدلالية. إليكم الأسباب - فرقعة ، فرقعة ، فرقعة - لماذا ستكون مكتبة أفضل إذا فعلت ذلك. فيما يلي الأسباب - bang، bang - لماذا يكون من المجدي للقائمين على الصيانة زيادة رقم الإصدار بطريقة تتوافق مع semver.

بعد ذلك ، الأمر متروك للقائمين على الصيانة. إذا كنت لا توافق على موقفهم ، فهناك مكتبات بديلة لاستخدامها .. يمكنك تفرع المشروع (كما فعل الآخرون). يمكنك كتابة منشور مدونة يصبح شخصيًا كما يحلو لك.

لكن دعونا نحاول أن يكون لدينا خلاف مدني.

أنا لا أفهمraganwald. من الذي يصبح شخصيًا؟

أنا لا أهاجم أي شخص. أنا أشير إلى أن semver هو جزء من عقد API الذي تدخل فيه عندما تنشر حزمة إلى npm أو bower.

إذا خرقت هذا العقد ، فإنك تكسر رمز الآخرين. هذا غير لائق.

يعمل npm جيدًا لأننا جميعًا نتفق على بعض القواعد التي تحافظ على عمل الوحدات النمطية الخاصة بنا مع بعضها البعض بشكل جيد. إذا خالفت هذه القواعد ، فإنك تكسر الوحدات الأخرى التي تحاول العمل مع قواعدك. أنت تكسر تطبيقات الإنتاج التي تعتمد على الكود الخاص بك.

السؤال ليس "هل يجب أن نستخدم semver؟" السؤال هو ، "هل نريد أن نكون مواطنين صالحين في هذا النظام البيئي؟"

النقطة الأساسية هي أنه في مشروع مثل الشرطة السفلية ، _ كل تغيير يكسر لشخص ما. إذا أزلنا حارسًا فارغًا من _.extend (لاستخدام مثال عشوائي) لأنه يسبب خطأ لشخص ما ، ويخلق خطأ لشخص آخر ، فهل هذا تصحيح؟ هل هذه نسخة ثانوية؟ رائد؟

بالنسبة إلى Underscore و Backbone ، لا أعتقد أنه من غير المعقول تثبيت تبعياتك. لا يعد semver التالي شرطًا للنشر إلى أداة حزم.

النقطة الأساسية هي أنه في مشروع مثل Underscore ، كل تغيير ينفصل عن شخص ما.

أنت تقفز إلى أقصى الحدود لتبرير موقفك. الحقيقة أنه توازن. هناك واجهة برمجة تطبيقات شائعة وحالات حافة وسلوك موثق. من الممكن جدًا قضاء فترة من الوقت دون مواجهة إصدار رئيسي ببساطة عن طريق إصلاح الأخطاء وإضافة وظائف.

ما يعنيه هو أن القائمين على الصيانة يجب أن يفكروا ويخططوا. هذا يعني أنه قد يتعين عليك إنشاء خارطة طريق للميزات أو التغييرات التي لا يمكن معالجتها دون كسر التوافق الخلفي وهذا جيد.

قام Underscore بإصلاح إصدارات التصحيح وإدخال تغييرات كسر رئيسية. هذا شيء يمكن للقائمين على الصيانة التحكم فيه تمامًا.

بالنسبة إلى Underscore و Backbone ، لا أعتقد أنه من غير المعقول تثبيت تبعياتك.

يجب أن تكون هناك رسالة / تحذير في الوثائق بالتأكيد.

@ akre54 قد يؤدي تغيير ميزات _undocumented_ أو _أخطاء موثقة_ إلى كسر التعليمات البرمجية التي تعتمد عليها ، لكن المستخدمين يعتمدون على ميزات وأخطاء غير موثقة على مسؤوليتهم الخاصة.

إن تجاهل semver يعرض _ كل مستخدم_ لواجهة برمجة التطبيقات الخاصة بك للخطر. يقوم الأشخاص بإصلاح الأخطاء في المشاريع الكبيرة مفتوحة المصدر التي تتبع semver طوال الوقت ، ولكن من النادر حقًا رؤية أعداد كبيرة من الإصدارات في النظام البيئي npm.

لماذا هذا؟

نظرًا لأن _ جميع واجهات برمجة التطبيقات الجيدة تتبع مبدأ الفتح / الإغلاق_ (مفتوح للتمديد ، مغلق لكسر التغييرات) قدر الإمكان ، حتى يتمكن المستخدمون من مواكبة واجهة برمجة التطبيقات ، ولا تؤدي التغييرات إلى كسر الشفرة الحالية.

للإضافة إلى الحكايات ، تم أيضًا كسر الكود الخاص بي بواسطة المطبات السفلية في الماضي. لقد لجأنا إلى الالتزام بـ node_modules لمنع ذلك لأن --save --save-exact لم يفلح. إذا كانت تبعية المستوى الثاني تعتمد على Underscore وتستخدم إصدار ^x.y.z ، فإن تطبيقك لا يزال معطلاً.

بالنسبة لأرقام الإصدارات التي تشير إلى التقدم ، فلا يهمني. استخدام الإصدار 2.1.3 أو 143.3.2 لا فرق بالنسبة لي. لا يتم قياس تقدم المكتبة ونضجها بأرقام الإصدارات. أنا فقط لا أريد مكالمة هاتفية بعد ظهر يوم الأحد لأن شخصًا ما قام بتحديث التبعية التي تعتمد على underscore@^x.y.z .

: thumbsup: نعم. يوضح braddunbar نقطة لم أذهب إليها بعد - إن تجاهل semver يجعل الحزمة الخاصة بك حزمة خطيرة وخبيثة ، لأن هذا التغيير المعطل قد يظل باقياً في أي مكان.

إنه - على وجه التحديد مطلب مرهق - لإجبار المستخدمين على تعقب الأعطال في كود الطرف الثالث الذي يعتمد على الحزمة المعطلة.

IMO ، يُقاس التقدم الحقيقي للمكتبة والنضج في الموثوقية ، ويقطع semver شوطًا طويلاً نحو تحقيق هذا الهدف.

يجب أن تكون هناك رسالة في الوثائق بالتأكيد.

قطعا. يسعدني إضافة واحدة إذا كان هذا ما قررناه.

أنا لست ضد نظام إصدار أفضل (يعلم الرب أنه من المؤلم الانتظار لأشهر حتى يتم نشر إصلاح الخطأ الصغير الخاص بك) ، لكنني لست متأكدًا من أن "Follow semver" هي الإجابة الصحيحة الصحيحة.

في الوقت الحالي ، لا أعتقد أنه من المهم أن تكون الإجابة الصحيحة. إنه _is_ المجتمع يقبل الإجابة.

لا أعتقد أن أي شخص قال "اتبع semver" هو الجواب الصحيح الوحيد لنظام إصدار أفضل. ما قلناه هو أنه عقد واجهة برمجة تطبيقات npm ، وأن كسر هذا العقد يضر.

jdalton و dilvie كيف تقترح علينا التعامل مع الإصدارات؟ ماذا عن قبول الميزات؟ "استخدام semver" لا يخبرنا بأي شيء حقًا.

هل يجب أن نعيد ميزات مثل _.matches بضعة أشهر حتى نتمكن من انتظار إصلاحات الأخطاء الخاصة بالشفرة الحالية ، أم يجب أن نطلقها الآن ونترك للأشخاص طرح مشكلات التنفيذ؟

أعتقد أن semver ببساطة لا ينطبق بالكامل هنا.

الترويج الذاتي الوقح: استخدم التحديث التالي https://github.com/bahmutov/next-update لاختبار ما إذا كان يمكن تحديث التبعيات أولاً دون كسر مشروعك. لقد وجدت باستمرار تغييرات متقطعة في وحدات مختلفة على الرغم من التغيير *.*.x ، لذا فأنا الآن لا أثق في أي إصدارات معلن عنها ذاتيًا.

هل تعتقد أن هذا المشروع عبارة عن ندفة ثلجية؟ Lo-Dash هي أساسًا Underscore ++ ، ولا يمثل semver التالي مشكلة لـjdalton.

قبول الميزات الجديدة:

هل يكسر عقد API الحالي؟

نعم؟ - نتوء رقم الإصدار الرئيسي.
رقم؟ - نتوء رقم الإصدار الثانوي.

قبول إصلاحات الأخطاء / التصحيحات الصغيرة:

هل يكسر عقد API الحالي؟

نعم؟ - نتوء رقم الإصدار الرئيسي.
رقم؟ - رقم إصدار التصحيح النتوء.

إن الطريقة التي تختارها لجدولة الإصدارات الرسمية متروكة لك تمامًا. فقط تأكد من أن الإصدار متوافق مع semver حتى لا تكسر كود الآخرين.

متفق عليه مع dilvie ، على سبيل المثال https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 ربما كان يجب أن يكون نتوءًا كبيرًا لأننا أسقطنا دعم المصفوفات المتفرقة. يجب أن يكون الإصدار التالي بمثابة عثرة كبيرة حيث سنقوم بإضافة طن من السكر الجديد عبر lookupIterator وإسقاط التكرارات الأصلية.

إذا كان لابد من تغيير توثيق الوظيفة ، فمن الواضح أنه تغيير رئيسي

لقد دخلت في مناقشة موجزة حول هذا في JSconf هذا العام. ليس لدي الوقت للخوض في التفاصيل ، هنا ، ولكن:

توقف عن الخلط بين "الإصدار" الذي يتعامل مع البشر ، والتوافق المواجه للكمبيوتر (أو المواجه لنظام البناء) "توافق واجهة برمجة التطبيقات". توقف.

الإصدار: "هذا الشيء الذي يعجبني به ميزات جديدة ، أو أي شيء آخر يجب أن أهتم به عندما يكون لدي الوقت." يوجد iPhone جديد. هناك نظام تشغيل جديد. هناك Ember جديد. هناك تقرير منقح جديد حول نظام اللغة الخوارزمية.

توافق API: "تم تحديث هذا الشيء لإصلاحه، وهذا قد / سوف يكسر الطريقيمارس هذا الشيء ". تم استبدال قابس الطاقة الخاص بـ iPhone. OS X مهمل Resource-forks. أوقف إمبر أسماء أسلوب العمل. المخطط الآن حساس لحالة الأحرف.

يحدث الأخير _ أثناء_ ، أو _ بجانب _ ، السابق ؛ لكن الأول لا يعتمد بالضرورة بأي حال من الأحوال على الأخير أو حتى مرتبط به. يجب تعقبها وتحديدها بشكل منفصل (إذا كنا سنقوم بالفعل بتخصيص نظام إصدار ، يا يسوع). (إن مفهوم "الإصدار الدلالي" الشائع في مجتمع JS - بشكل خاص - غير مفهوم ومريع ؛ ولكن مرة أخرى ، ليس شيئًا أريد الخوض فيه بالتفصيل في سلسلة تعليقات إصدار شخص آخر.)

tl ؛ dr: إنهم لا يفسدون النظام البيئي الخاص بك عن طريق اختيار مسارهم الخاص. (_خاصة_ عندما يكون هذا المسار معيبًا بشكل رهيب.) أتمنى أن تفعل المزيد من المشاريع. اذهب واستخدم شيئًا آخر ، إذا كنت منحني الشكل فوقه.

elliottcable - متفق عليه بشأن مواجهة الإنسان مقابل مواجهة الكمبيوتر ... طالما أن الوجه البشري لا يشبه مواجهة الكمبيوتر ، لذا فإن الخلط يكون أقل إشكالية.

ربما نطلق على الإصدار التالي الذي يواجه الإنسان شيئًا مثل "ندفة الثلج" بدلاً من nnn

لا أوافق تمامًا مع الجزء الأخير. عندما تتظاهر باتباع عقد واجهة برمجة التطبيقات (API) ثم تخرقه ، فإن الأشياء تنكسر. يكلف الآخرين الوقت الحقيقي والمال الحقيقي. مع وجود مشروع شائع مثل الشرطة السفلية ، من المحتمل أن يكون هناك الكثير من الضرر الحقيقي.

هل يكسر عقد API الحالي؟

ننظر إلى الوراء إلى الحجج الأولى في هذا الموضوع. "كل شيء في Underscore هو في الأساس مساحة سطحية" ، ergo ، كل شيء ، موثق وغير موثق ، هو جزء من عقد API الخاص به. أي تغيير هو تغيير للجميع.

Lo-Dash ، كونها "Underscore ++" لا تتعامل مع ما يقرب من العديد من التغييرات في الميزات لأنها يمكن أن تتبع بأمان وراء Underscore في العمل على الميزات الرئيسية. تتم تحسينات Lo-Dash بشكل أساسي تحت الغطاء أو في إضافة بعض الطرق ، وليس إعادة التفكير بشكل أساسي في ميزاتها.

@ akre54

كيف تقترح علينا التعامل مع الإصدارات؟ ماذا عن قبول الميزات؟ "استخدام semver" لا يخبرنا بأي شيء حقًا.

يمكنك قبول واجهة برمجة تطبيقات جديدة أو حتى بعض التحسينات على واجهة برمجة التطبيقات الحالية. إذا أضفت واجهة برمجة تطبيقات جديدة أو تحسينات (لا تكسر التوافق) ، فسيكون تحديث إصدار ثانوي.

هل يجب أن نعيد ميزات مثل _.matches بضعة أشهر حتى نتمكن من انتظار إصلاحات الأخطاء الخاصة بالشفرة الحالية ، أم يجب أن نطلقها الآن ونترك للأشخاص طرح مشكلات التنفيذ؟

أعتقد أن _.matches هو أمر بسيط جدًا. سيكون هناك دائما إصلاحات للأخطاء.

أعتقد أن semver ببساطة لا ينطبق بالكامل هنا.

بالتأكيد يفعل. لقد بدأت في التسلل إلى مخاوف دورة الإصدار ، والتي هي منفصلة عن semver ، لكنني سأتبعك هناك.

dilvie : سأبقى بعيدًا عن بقية الجدل ، لكن مع طرح هذا: حقًا ، أحب اقتراحك باتباع اصطلاح "اسم الإصدار". (=

بالنسبة للجزء المواجه للإنسان ، فأنا من أشد المعجبين بإصدارات بنمط less :

> 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

... قم بإقران ذلك باسم جميل ، لتوضيح أننا نتحدث عن "الاهتمام" - الإصدار ، وليس التوافق مع واجهة برمجة التطبيقات ، وستحصل على مزيج فائز.

+1 لـ Underscore 42: "Silly Sheltie."

(بالنسبة للجزء المواجه لنظام البناء ، لدي بعض وجهات النظر المثيرة للجدل حول التوافق الآلي والتوليدي لواجهة برمجة التطبيقات. دعنا نخرج هذا الهراء من أيدي المشرفين المعرضين للخطأ ، من فضلك ، ونهاجمها بالتحليل الثابت أو الزحف الديناميكي.)

@ akre54

Lo-Dash ، كونها "Underscore ++" لا تتعامل مع ما يقرب من العديد من التغييرات في الميزات لأنها يمكن أن تتبع بأمان وراء Underscore في العمل على الميزات الرئيسية.

ماذا يعني ذلك حتى؟ يتعامل Lo-Dash مع _ المزيد من التغييرات_ ويتبع إصداره الخاص المنفصل عن Underscore. لقد تغير Lo-Dash كثيرًا لدرجة أنه كان عليه أن يقدم تصميمًا متوافقًا مع Underscore لمواصلة دعمه لكونه بديلاً عن الخدمة. لدينا ميزات وأساليب مختلفة ومخاوف مختلفة متوافقة مع API.

تتم تحسينات Lo-Dash بشكل أساسي تحت الغطاء أو في إضافة بعض الطرق ، وليس إعادة التفكير بشكل أساسي في ميزاتها.

هذا ليس هو الحال أيضا. يتحرك Lo-Dash بوتيرة أسرع ويصطدم بمواجهة الخلف بشكل متكرر. هذا هو سبب استمرارنا في الإصدار 2.x ~ v3.x. Lo-Dash تشبه الشرطة السفلية. إذا كان بإمكان Lo-Dash متابعة semver ، فيمكن تسطير أسفل السطر. لقد فعلت ذلك لمدة 2 سنوات حتى الآن. حججك ببساطة تسقط في مواجهة الواقع.

لقد كنت في هذا الطريق من قبل حتى أتمكن من مساعدتكم جميعًا للوصول إلى هناك أيضًا.
بالنسبة للمبتدئين ، فإن الإصدار التالي للعلامة السفلية سيكون 2.0 رائعًا.

أشعر بالفضول كيف يعتقد الجميع أنه ينبغي تعريف "كسر التغيير". _Every_ تغيير ميزة جديدة للشرطة السفلية هو تغيير جذري لشخص آخر.

لنأخذ على سبيل المثال جميع التغييرات الأخيرة التي تم إجراؤها على _.each . هل يجب أن نتصادم عندما قمنا بتغيير قيمة الإرجاع _.each لإرجاع القائمة الأصلية ؟ هل هذا خطأ؟ ميزة جديدة؟ تغيير غير متوافق؟ لقد أعاد undefined من قبل ، لذلك من غير المحتمل أنه كسر رمز أي شخص.

هل يجب أن نتصادم عندما سمحنا بإعادة تعيين المساعد الداخلي each خارجيًا ؟ هل يمكن أن يكون هذا قد كسر رمز شخص ما؟ لم يتم تغيير API العامة هناك.

من الواضح أن تغيير _.each لتجنب المصفوفات المتناثرة واستخدام الحلقات for بدلاً من forEach الأصلي هو كسر بالنسبة للبعض ، ولكن بما أن المصفوفات المتفرقة ميتة فمن يهتم حقًا؟ هل هو شيء يجب علينا دفع نسخة رئيسية منه؟ هل هذا خطأ؟

أعتقد أننا تأخرنا عن موعد حدوث عثرة كبيرة في الإصدار (حدث الكثير في 219 التزامًا ). إن إصدار 2.0 وترسيخ سياسة الإصدار لدينا من شأنه أن يقطع شوطًا طويلاً هنا.

@ akre54

كل تغيير ميزة جديدة إلى Underscore هو تغيير جذري لشخص آخر.

ليس بالضرورة.

لنأخذ على سبيل المثال جميع التغييرات الأخيرة على _.each. هل يجب أن نتصادم عندما قمنا بتغيير قيمة إرجاع _.each لإرجاع القائمة الأصلية؟ هل هذا خطأ؟

إنه ليس إصلاحًا للأخطاء ، إنه تحسين. هل هي غير قابلة للكسر؟ - من المحتمل أن يكون تغييرًا آمنًا لأنه من غير المحتمل أن يتم الاعتماد على قيمة الإرجاع البالغة _.each وليس هناك شيء أبلغ عنه المطورون بأنه عقبة عند التبديل إلى Lo-Dash. إذا كنت في شك من جانب الكسر ، أو اختبر المياه بإطلاق RC. إذا كان التغيير هو السماح بالخروج مبكرًا من _.each ، فسأقول أنه كان تغييرًا فاصلًا واضحًا حيث واجه المطورون ذلك عند استخدام CoffeeScript.

هل يجب أن نتصادم عندما سمحنا بإعادة تعيين كل مساعد داخلي خارجيًا؟ هل يمكن أن يكون هذا قد كسر رمز شخص ما؟ لم يتم تغيير API العامة هناك.

أود أن أقول أن هذا يندرج تحت تفاصيل التنفيذ غير الموثقة. في ذلك الوقت ، لم يسمح التغيير بأي شيء جديد لأن Underscore لا تزال متفرعة للطرق الأصلية. يندرج هذا التغيير ضمن المجموعة الأكبر من التغييرات في ما بعد 1.6.0 لذا يمكن أن يصل إلى 2.0.

من الواضح أن تغيير _.each لتجنب المصفوفات المتناثرة واستخدام الحلقات for بدلاً من forEach الأصلي هو كسر بالنسبة للبعض ، ولكن بما أن المصفوفات المتفرقة ميتة فمن يهتم حقًا؟ هل هو شيء يجب علينا دفع نسخة رئيسية منه؟ هل هذا خطأ؟

يمكن اعتباره إصلاحًا للأخطاء ولكنه بالتأكيد تغيير جذري. هذا هو أحد الأشياء التي يواجهها المطورون عند التبديل إلى Lo-Dash. نظرًا لكيفية استخدام Underscore ، باستخدام أصلي عند توفره ، فإنه سيخفي استخدام المصفوفة المتفرقة ولن يواجه المطورون المشكلة إلا إذا اختبروا في المتصفحات القديمة. ومع ذلك ، مع هذا التغيير ، سيتم تنبيه مطوري البرامج إلى استخدامهم لمصفوفاتهم المتفرقة عاجلاً ، في المتصفحات الحديثة ، لذلك هناك احتمال أن تواجه التعليمات البرمجية التي كانت تعمل سابقًا عقبة.

أعتقد أننا تأخرنا عن موعد حدوث عثرة كبيرة في الإصدار (حدث الكثير في 219 التزامًا). إن إصدار 2.0 وترسيخ سياسة الإصدار لدينا من شأنه أن يقطع شوطًا طويلاً هنا.

: +1:

كسر التغيير (تغييرات كسر الجمع)

(الحوسبة) تغيير في جزء واحد من نظام برمجي قد يتسبب في فشل المكونات الأخرى ؛ يحدث غالبًا في مكتبات مشتركة من التعليمات البرمجية التي تستخدمها تطبيقات متعددة
"لا يمكن إصلاح الإدخالات القديمة بدون تغيير فاصل ، لذا أعد تعيين القديم إلى الجديد في استيراد lib."

بعض هذا يتطلب بعض التفكير والحكم. قد يكون صحيحًا أن جميع التغييرات تكسر رمز شخص ما ، ولكن إذا وافق جميع المشاركين على استخدام مبدأ الفتح / المغلق كدليل لما يشكل كسرًا ، فإنه يجعل حياة الجميع أسهل.

لذلك ، فإن إضافة أي خاصية أو طريقة إلى واجهة برمجة التطبيقات لا يعد تغييرًا فاصلًا (واجهة برمجة التطبيقات مفتوحة للتمديد ، ولكنها مغلقة أمام التغييرات غير المتوافقة مع الإصدارات السابقة).

تتطلب التغييرات في تواقيع الوظيفة مزيدًا من التفكير.

هل يجب أن نتصادم عندما قمنا بتغيير قيمة إرجاع _.each لإرجاع القائمة الأصلية؟

هل كانت تلك ميزة موثقة لواجهة برمجة التطبيقات خدمت غرضًا ما؟ على سبيل المثال ، ترجع بعض الوظائف غير محددة عندما لا تؤدي المدخلات التي تم تمريرها إلى إخراج معقول. لا يبدو أن هذا هو الحال مع each ... لذا ، ربما لم ينكسر.

من ناحية أخرى ، فإن تجنب المصفوفات المتناثرة لديه إمكانية أكبر لتغيير قيم الإرجاع التي يعتمد عليها المطورون ، ومن الواضح أن هذا تغيير كبير ، وأي شخص يستخدم المصفوفات المتفرقة يهتم.

قد لا تنجو المصفوفات المتفرقة من ES6 ، لكنها لم تمت بعد.

@ akre54
في بعض الأحيان ، لا تكون الإجابة على ما إذا كان التغيير ينكسر أم لا مباشرة. في هذه الحالات ، يساعد السياق والتاريخ والبيانات. من حسن الحظ أنني تمكنت من استخدام Lo-Dash كأرض اختبار للميزات الجديدة ومعرفة التغييرات التي ترفع عن طريق المطورين القادمين من Underscore. يمكن للشرطة السفلية بدورها استخدام ذلك للمساعدة في اتخاذ قرارات مستنيرة بشأن تأثير التغييرات.

على الأقل ، سيساعد semver التالي على منع حدوث تغييرات فاصلة كبرى في إصدارات التصحيح ويشجع المطورين على التفكير في تأثير تغييراتهم. هذا فوز للجميع.

jdalton ، قانون الفصل. :)