أتساءل عما إذا كان بإمكاننا إعطاء المكونات الإضافية رقم إصدار للسماح للمكونات الإضافية بإدراج الحد الأدنى والأقصى لإصدار discourse الذي يمكنها التوافق معه.
حتى لا نواجه الموقف الذي يتم فيه تحديث المكون الإضافي الخاص بنا، ولكن إصدار discourse الخاص بنا متأخر ويتسبب في تعطل الموقع بأكمله.
هناك فئتان عريضتان من الإضافات والمكونات الإضافية لـ TC:
تحافظ الإضافات الرسمية بالفعل على التوافق، وإذا لم تكن متوافقة، فعادةً ما يكون لديك مطور براتب يصلح الأمور في غضون أيام.
من الصعب بما فيه الكفاية على القائمين على الصيانة الحفاظ على التوافق، ناهيك عن تتبع ما إذا كانوا كذلك أم لا.
هناك نسختان فقط عمليتان للصيانة:
مستقرتم اجتياز الاختباراتيمكنك استخدام نظام التثبيت (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) للتثبيت لـ مستقر بالفعل. قد يكون من الجيد جدًا عرض ذلك بطريقة ما لإظهار التوافق الصريح، ولكنه لا يعني أن المكون الإضافي غير متوافق إذا لم يكن هناك تثبيت.
يمكن عرض التوافق مع أحدث إصدار باستخدام علامة خضراء من CI على github.
يعتمد ذلك على شيئين:
هذا الأخير هو طلب كبير لمقدمي الإضافات من طرف ثالث الذين يقومون بالأشياء مجانًا.
بالنسبة للإضافات غير الرسمية، فإن طلب الميزة الخاص بك يرجع إلى تمويل لائق للإضافات من طرف ثالث.
كمؤلف إضافات مخضرم مر بهذه التجربة، يمكنني أن أخبرك أنه من المستحيل تقريبًا تمويل إضافات الطرف الثالث.
السبب الوحيد الذي يجعل إضافاتي لا تزال تعمل هو:
هذا قيّم بالنسبة لي ولكنه له حدوده.
أود أن أقول إن تطوير إضافات الطرف الثالث قريب من 
في نظام Discourse البيئي، مع عدد قليل جدًا من المطورين القادرين على الحفاظ على الأمور تعمل ضد السرعة المتطلبة للغاية للنواة.
استثناءات أخرى:
بالنظر إلى أنه لا يمكنك حقًا الاعتماد إلا على الإضافات الرسمية المتوافقة (وربما عدد قليل إضافي من المطورين النشطين جدًا مثلي أو Communiteq)، أقترح عليك ببساطة التركيز على استخدام الإضافات official وبالنسبة لتلك أعتقد أن طلب الميزة الخاص بك زائد عن الحاجة لأن هناك عملية مطبقة لتلك الأشياء لتتبع النواة.
لست متأكدًا من كيفية تحديد إصدار أقصى متوافق لمكون إضافي. يمكن لمكون إضافي بسيط أن يقول على الأرجح إنه يعمل حتى 4.0 على الأقل، وعندما يأتي الإصدار 4.0، قد يظل يعمل لأن CDCK لم يقدم أي تغييرات جوهرية.
ولكن ربما استخدم المكون الإضافي البسيط شيئًا قامت CDCK بإهماله في 3.8 وإزالته في 3.10… من الصعب جدًا أخذ ذلك في الاعتبار.
لأنك لا تستطيع.
سيصبح قديمًا بمجرد إصدار الالتزام التالي.
ولكن الأمر بسيط:
ثم تحقق من العلامة الخضراء قبل التثبيت.
لقد كنت ألعب بهذا التحدي ووجدت حلاً في Github.
لذلك، فإن مجرد وجود علامة خضراء لأحدث مهمة CI ليس كافياً، حيث قد تكون هناك تغييرات حديثة قد تؤدي إلى تعطل المكون الإضافي. بشكل أساسي، تحتاج إلى إعادة تشغيل مهام CI عندما تقوم Discourse بتحديث الفروع.
في مستودع المثال هذا قمت بتطوير حل فعال. إنه في الأساس سير عمل مجدول يتحقق من الفروع المهمة لمستودع Discourse لمعرفة ما إذا كانت هناك تغييرات، وإذا كانت هناك، فسيؤدي ذلك إلى تشغيل سير العمل العادي لـ CI الذي يجب أن يقوم بتشغيل مجموعة الاختبارات. في ملف القراءة الخاص بك، يمكنك بعد ذلك وضع بعض الشارات لإظهار كيف تم تشغيل مهام سير عمل CI ضد أحدث التغييرات.
سير العمل للمراقبة يعمل في ثوانٍ. لذلك، عند جدولته، سيستهلك دقيقة واحدة فقط من وقت إجراءات Github.
من الواضح أن موثوقية هذه الإعدادات بأكملها تعتمد على جهود مطور المكونات الإضافية/مكونات الثيم في إنشاء مجموعة اختبارات جيدة.
ولا يزال لديك مشكلة تجربة المستخدم حيث لا تعرف من صفحة “التحديث” في Discourse ما إذا كانت أحدث مهمة CI قد فشلت لإصدار معين.
لذلك، بالإضافة إلى وجود سير عمل للمراقبة يعيد بناء مكون إضافي عند تغيير فرع Discourse، تحتاج إلى إنشاء قطعة بناء تسجل النتيجة (نجاح/فشل). في بيانات المكون الإضافي الخاص بك، يجب أن تكون قادرًا على الإشارة إلى هذه القطعة، ويجب على Discourse استرداد هذه القطعة لعرض التوافق/النتيجة في واجهة التحديث.
إنه ليس بناءً مضمونًا، ولكنه شيء.
لهذا السبب كتبت “عند كل التزام جديد للنواة في CI” 
كان لدينا لوحة تحكم على Pavilion لفترة طويلة قامت بكل هذا بالضبط