تثبيت إصدارات الإضافات والسيمات للتركيبات القديمة من Discourse (فروع d-compat)

:open_book: الخلفية

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

للسدّ من هذه الفجوة، يمكن إخبار Discourse بفحص نسخة أقدم “مثبتة” (pinned) من القالب/الإضافة. يوجد آليتان لهذا الغرض، يتم فحصهما بالترتيب:

  1. فروع git باسم d-compat/<YYYY>.<M> في مستودع القالب/الإضافة (الطريقة الأساسية — موصى بها لجميع الإصدارات المثبتة الجديدة).
  2. ملف YAML باسم .discourse-compatibility في جذر المستودع (الآلية الأصلية، ما زالت مدعومة كحل بديل).

إذا وُجد الاثنان، فإن الفرع له الأولوية.

:herb: نظام الفروع d-compat/<YYYY>.<M>

تستخدم إصدارات Discourse أرقاماً تاريخية مثل 2025.5، 2025.6، إلخ. عند تحديث Discourse لإضافة أو قالب من git، يسأل المستودع: “هل لديك فرع باسم d-compat/<YYYY>.<M> يطابق إصداري؟” (مثلاً d-compat/2025.5 لـ Discourse 2025.5.x). إذا كان كذلك، يقوم Discourse بفحص طرف ذلك الفرع بدلاً من main.

لا يتم تنفيذ عملية البحث إلا عندما يكون الفحص المحلي على الفرع الافتراضي للمستودع. إذا كنت قد ثبتّ (pin) عمداً على فرع مختلف، يتم تجاوز منطق d-compat ويتم احترام تثبيتك.

لدعم إصدار أقدم من Discourse بهذا النظام:

  1. أنشئ فرعاً باسم d-compat/<YYYY>.<M> من التزامات المعروفة بأنها تعمل على ذلك الإصدار (مثلاً git checkout -b d-compat/2025.5 <commit>).
  2. ادفعه (push) إلى origin. قد ترغب في حماية الفرع من الحذف العرضي.
  3. أضف أي التزامات مخصصة للعودة (backport) إلى ذلك الفرع. ستلتقط مواقع Discourse على 2025.5.x هذه التحديثات تلقائياً عند التحديث التالي؛ بينما ستستمر مواقع Discourse الأحدث في تتبع الفرع الافتراضي.

لا تحتاج إلى لمس .discourse-compatibility على الإطلاق عند استخدام الفروع.

:gear: إنشاء الفروع تلقائياً (create-d-compat-branch.yml)

في الممارسة العملية، نادراً ما تحتاج إلى إنشاء هذه الفروع يدوياً. تتضمن هياكل القوالب والإضافات الافتراضية عملية d-compat-branch.yml تعمل يومياً، وتتحقق من إصدارات جديدة من نواة Discourse، وتدفع فروع d-compat/<YYYY>.<M> المطابقة عند الحاجة.

إذا كان مستودعك قد أُنشئ من نسخة أقدم من الهياكل، فما عليك سوى نسخ ملف d-compat-branch.yml إلى مجلد .github/workflows لديك لتفعيله.

:git_merged: عكس تصحيح إلى فرع d-compat

عندما تكون قد أضفت تصحيحاً على الفرع الافتراضي والذي يحتاج أيضاً للوصول إلى المواقع على إصدار أقدم من Discourse:

  1. أنشئ فرعاً من فرع d-compat المستهدف ونسخ التصحيح (cherry-pick):

    git fetch origin
    git checkout -b backport/my-fix-2025.5 origin/d-compat/2025.5
    git cherry-pick <commit-sha>
    git push -u origin backport/my-fix-2025.5
    
  2. افتح طلب سحب (PR) مع d-compat/2025.5 كـ فرع أساسي (وليس main). احصل على مراجعته وادمجه بنفس الطريقة التي تعالج بها أي طلب سحب آخر.

  3. كرر العملية لكل فرع d-compat/<YYYY>.<M> أقدم يحتاج إلى التصحيح.

ستلتقط المواقع على 2025.5.x التزام الدمج المدمج في تحديثها التالي.

حل بديل قديم: ملف `.discourse-compatibility`

إذا لم يوجد فرع d-compat مطابق، يلجأ Discourse إلى ملف YAML باسم .discourse-compatibility في جذر المستودع، والذي يربط إصدارات Discourse بمرجع git (git ref) لإضافتك/قالبك:

< 3.2.0.beta2-dev: abcde

يختار Discourse أدنى مدخل يطابق إصدار النواة قيد التشغيل، لذا أي شخص على < 3.2.0.beta2-dev سيفحص الالتزام abcde. استخدم < (أو <= القديم، وهو الافتراضي عند عدم تحديد عامل) لتحديد حد الإصدار. لجأ إلى هذا الحل فقط إذا تعذر على نظام الفروع التعبير عما تحتاجه.


هذا المستند خاضع للتحكم بالإصدارات - اقترح تغييرات على github.

17 إعجابًا

إذا كان الإصدار < 3.5.0.beta8-dev، فهل سيشمل 3.5.0؟

لا. يُعتبر الإصدار 3.5.0 “أعلى” من الإصدار التجريبي “3.5.0.beta8-dev”.

يمكنك دائمًا تجربة المقارنات على وحدة تحكم Ruby:


> Gem::Version.new("3.5.0") < Gem::Version.new("3.5.0.beta8-dev")
=> false
5 إعجابات

مفهوم. شكرا على الشرح!

إعجاب واحد (1)

تم تحديث هذه الوثيقة لوصف استراتيجية d-compat/* الجديدة من https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536، والتي أصبحت متاحة للاستخدام الآن.

5 إعجابات

ستتطلب استراتيجية d-compat/<YYYY>.<M> إنشاء فرع لكل إصدار محدد، أليس كذلك؟ لا يمكن تحديد نطاق كما هو الحال في بناء .discourse-compatibility.

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

على سبيل المثال، الإصدار المستقر طويل الأمد الحالي هو 2026.1، والإصدار الحالي هو 2026.6، وأحدث إصدار هو 2026.7، لا يزال مدعومًا في 2026.5. عندما أقوم بنقل إضافتي إلى الإصدار المستقر طويل الأمد الجديد (2026.7)، بينما لا يزال Discourse يدعم الإصدار المستقر طويل الأمد القديم. هل سأحتاج إلى إنشاء الفروع التالية:

  • d-compat/2026.1
  • d-compat/2026.2
  • d-compat/2026.3
  • d-compat/2026.4
  • d-compat/2026.5
  • d-compat/2026.6

حيث أن الإصدارات من .2 إلى .5 (بما في ذلك) قد انتهت دورة حياتها (EOL) في Discourse، لكن قد لا يزال بعض المستخدمين يستخدمونها.

أم أن Discourse يجد الفرع الأنسب إذا كان هناك فرع مفقود، بدلاً من افتراض الفرع الرئيسي؟

على سبيل المثال، إذا كنت أستخدم الإصدار 2026.5 وكانت الفروع الوحيدة المتاحة هي d-compat/2026.1 و d-compat/2026.6. أي فرع سيتم استخدامه؟

  1. d-compat/2026.1 لأنه أقرب إصدار متوافق؟
  2. main لأنه لا يوجد فرع محدد؟
إعجاب واحد (1)

نعم، يتطلب كل إصدار من Discourse core فرعًا واحدًا. نوصي بأتمتة إنشائهم:

سيتم استخدام main.

إعجابَين (2)