Backbone: اتبع SemVer

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

إذا اتبعنا الإصدار "الدلالي" بدقة ، فمن المحتمل أن يكون Backbone.js 43.0.0 الآن - وهو ما لا يساعد أي شخص في تقييم التقدم الفعلي للمشروع.

لذا ، كما أحب المزاح - ليس الإصدار "الدلالي" ، الإصدار الرومانسي.

بالنظر إلى رقم الإصدار MAJOR.MINOR.PATCH ، قم بزيادة:

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

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

ولكن تجنب أي تغيير في واجهة برمجة التطبيقات ، وانتظار إصدار "رئيسي" ليكون جاهزًا سيكون بمثابة عائق كبير أمام التقدم. والبديل المتمثل في زيادة رقم الإصدار الرئيسي بشكل متكرر غير مفيد بشكل لا يصدق.

بصراحة ، أفضل مخططًا أبسط يستخدم أرقام إصدارات BIG.SMALL - كما تفعل معظم تطبيقات سطح المكتب ... لكنني سأقلق بشأن كسر مديري الحزم والأدوات الأخرى.

ما هي مشكلة التواجد في Backbone 43.0.0؟

• مُرسَل من Chrome 32.0.1700

+1 لـ spadgos @ question. أرقام الإصدارات عشوائية. لسبب ما ، لدينا تطبيقات ويب رشيقة تحاول البقاء ضمن نفس نطاقات أنظمة التشغيل. العديد من التطبيقات تنزعج من تجاوز العشر سنوات الماضية ... ولكن معظم المشاريع التي تصممها (Windows ، Linux ، إلخ) لها دورات تطوير لمدة عام / عدة سنوات قبل الإصدار ، لذا 1.x -> 2.x هي صفقة كبيرة. يتحرك المشروع المرن بسرعة كبيرة ، والزيادة بسرعة أمر منطقي أيضًا.

أنا أيضا لا أتفق مع المنطق وراء ذلك.

ماريونيت تعمل على الإصدار 1.2.3 في الوقت الحالي ، وهي تبذل قصارى جهدها لاتباع إصدار دلالية صارم. حتى الآن ، لم نواجه أية مشكلات على الرغم من أننا "كل مساحة السطح" أيضًا. لقد أضفنا ميزات جديدة. لقد أصلحنا الخلل. لكن الإصدار 1.0 لا يزال متوافقًا مع الإصدار 1.2.3. لقد قمنا بتأجيل التذاكر لإصدار v2 عندما تكون واجهة برمجة التطبيقات (API) أو نتوقع حدوث تغييرات في السلوك.

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

كما هو الحال ، فإن كسر التوافق في إصدار v1.1 يسبب الكثير من الألم لمطوري المكونات الإضافية والإضافات ، مثل فريق MarionetteJS. كان علينا إعادة ملء السلوكيات باستخدام التصحيحات في التعليمات البرمجية الخاصة بنا ، حتى نتمكن من البقاء قابلين للحياة لكل من الإصدارين v1.0 و v1.1 ... إنه ليس موقفًا ممتعًا. إن التأثيرات المتتالية لمكتبة أساسية مثل العمود الفقري لها تغييرات متقطعة ، هائلة ... لا يتأثر العمود الفقري فقط.

أوافق على أن هذا يبدو أشبه بحالة "لا أريد" بدلاً من "لا أستطيع". التغييرات المتقطعة مثل https://github.com/jashkenas/backbone/pull/2461 ليس لها إحساس حقيقي بالإلحاح ، ويمكن أن تنتظر تحديثًا رئيسيًا للإصدار إذا كنت لا تريد مشكلة 43.0.1.

بالنسبة لي ، فإن أكبر مشكلة مع العمود الفقري لا يحترم semver (من بين أمور أخرى) هي في التدريس وتبشير العمود الفقري. ليس من الرائع إخبار مجموعة من الطلاب أو العملاء المحتملين أن كل شيء في مجموعتك سيعمل بطريقة معينة ... باستثناء العمود الفقري.

لطالما كان هناك تحذيران كبيران عند "التبشير" Backbone: إنه ليس AMD خارج الصندوق ، ولا يحترم SemVer ، لذلك لا تأخذ أرقام الإصدار على محمل الجد. واحد من هؤلاء تم إصلاحه. دعونا نصلح الآخر.

بصراحة ، أفضل مخططًا أبسط يستخدم فقط أرقام إصدارات BIG.SMALL - كما تفعل معظم تطبيقات سطح المكتب ... لكنني سأقلق بشأن تعطل مديري الحزم والأدوات الأخرى.

jashkenas يمكننا دائمًا ترك الرقم الثالث عند .0 :)

من المحتمل أن يكون هذا مخططًا لغويًا لـ SemVer أقرب قليلاً مما نفعله الآن. ربما كان ذلك سيقلل من بعض عمليات القنص المشفرة والسياسية السلبية حول كيف أنه من الخطأ الفني بطريقة ما عدم اتباع SemVer.

أعتقد أن وجهة نظر بوب صحيحة في أنه من الأهمية بمكان أن نوضح بوضوح النظام الذي نتبعه ، بغض النظر عن النظام الذي نتبعه.

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

: +1: لسمفر. أنا مهتم في المقام الأول بإصدار برنامج معين ليس كمؤشر على تقدمه ولكن لمدى توافقه.

بشكل عام ، بعد الإصدار 1.0 (عندما أتوقع أن تكون الأشياء مستقرة وتعمل في الغالب) ، فإن أرقام الإصدارات لا معنى لها إلى حد كبير كمؤشرات للتقدم. قد يكون البرنامج X في الإصدار 10 أقل نضجًا ، ولديه ميزات أقل من البرنامج Y في الإصدار 2. إذا كنت تريد معرفة التقدم المحرز في جزء من البرنامج ، فعليك إلقاء نظرة على سجل التغيير أو خارطة الطريق.

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

إذا اتبعنا الإصدار "الدلالي" بدقة ، فمن المحتمل أن يكون Backbone.js 43.0.0 الآن - وهو ما لا يساعد أي شخص في تقييم التقدم الفعلي للمشروع.

مشكلة بسيطة جدًا / ربما غير موجودة. لا تتبع semver؟ مشكلة كبيرة.

: +1 :، semver أمر لا بد منه لمثل هذا المشروع الكبير.

أنا معknowtheory. 43.0.0 غريبًا بعض الشيء ولكن أعتقد أن 1.43.0 سيكون جيدًا ولن يحصل أي شخص على كسر مفاجئ بعد npm install .

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

: +1: كان سيمنع بعض المشكلات في # 2996 و # 2997 ، والمشكلات التي واجهها الآخرون مع العديد من إصدارات العمود الفقري الأخرى.

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

شكرًا ، ولكن اتباع الإصدار "الدلالي" بدقة لن يعمل جيدًا مع Backbone.

أعتقد أن الأمر يتعلق أكثر بعمل Backbone بشكل جيد لمستخدميه (مع إدارة التبعية). الذي سيضمن semver التالي ...

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

+ 1derickbailey

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

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

بالنسبة للحزم في npm أو bower ، فإن هذا ليس موضع نقاش.

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

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

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

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

لا ليس كذلك. npm install --save [email protected] ليس مطلبًا مرهقًا.

@ akre54 أنا مهتم بوجهة نظرك حول semver ، وأنا أعلم jashkenas ، لكن ما هي وجهة نظرك.

@ akre54 نعم ، إنه كذلك. تفترض npm أن جميع الحزم في المستودع تتبع semver . هذه هي الطريقة التي تحدد الحزم المتوافقة معها.

من المستند package.json :

"يجب أن يكون الإصدار قابلاً للتحليل بواسطة node-semver ، والذي يتم تجميعه مع npm كعنصر تبعية. (npm قم بتثبيت semver لاستخدامه بنفسك.)"

إذا كانت أرقام الإصدار لديك _lie_ عند تفسيرها على أنها semver ، فهذا ليس تحليلًا صحيحًا. وبالتالي ، فإنك تكسر العقد package.json ، وتكسر التوافق مع كيفية استخدام الناس لإصدارات الحزم في النظام البيئي npm.

هذه ليست مجرد مسألة تفضيل شخصي. إنها مسألة قابلية التشغيل البيني للحزمة.

هل من الممكن إجبار الحزمة الخاصة بك على اللعب بشكل جيد إذا لم تستخدم semver؟ _ بالتأكيد ، هذا صحيح ، ولكن إذا لم تسمعه بصوت عالٍ وجريء في الجزء العلوي من الملف التمهيدي الخاص بك - سيعرف القليل من المستخدمين أنه ضروري ، وعندما تُدخل تغييرًا فاصلًا ، يمكن أن ينكسر الكود الخاص بهم بسهولة.

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

npm install --save [email protected] ليس مطلبًا مرهقًا.

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

هناك أسباب وجيهة للغاية لمتابعة semver. "رقم الحزمة الخاص بي قد يصبح كبيرًا حقًا" هو سبب فظيع _لا _ لاستخدام semver. يعد تتبع تقدم تطبيقك سببًا ثانيًا بعيدًا لإصدارات الحزم. أهم وظيفة في الإصدار هي معرفة "هل سيعمل هذا الإصدار مع تطبيقي؟"

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

أعتقد أن الدرس المستفاد هنا هو "لا تستخدم ~ أو ^ عند السحب في Backbone عبر package.json"

@ akre54 أنا مهتم بوجهة نظرك حول semver

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

أعتقد أن الدرس المستفاد هنا هو "لا تستخدم ~ أو ^ عند السحب في Backbone عبر package.json"

نعم.

أعتقد أن الدرس المستفاد هنا هو "لا تستخدم ~ أو ^ عند السحب في Backbone عبر package.json"

لقد أوضحت أعلاه لماذا لا ينبغي أن يكون هذا هو الدرس الجاهز.

أعتقد أن الدرس المستفاد هنا هو "لا تستخدم ~ أو ^ عند السحب في Backbone عبر package.json"

هذا ما تفعله ، نتيجة لذلك ، لحماية التعليمات البرمجية الخاصة بك من الانهيار.

سيكون الدرس أشبه بـ "اتباع semver مفيد للجميع ، وليس القيام بذلك ليس كذلك".

يمكنني أن أقدر قيمة الإصدار "الرومانسي". من المؤسف أنهم لا يتعايشون جيدًا.

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

على الأقل العمود الفقري جيد جدًا بشكل عام في عدم تحطيم الأشياء.

تتعطل أشياء

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

بالنسبة لي ، هذه قيمة مضافة كبيرة ولكن من الواضح أن هذا يأتي على حساب التعقيد بالنسبة للمشرف.