ستتطلب استراتيجية d-compat/<YYYY>.<M> إنشاء فرع لكل إصدار محدد، أليس كذلك؟ لا يمكن تحديد نطاق كما هو الحال في بناء .discourse-compatibility.
لذا، إذا كنت أقوم بصيانة إضافة تعمل من الإصدار المستقر طويل الأمد (ESR) إلى أحدث إصدار. فعندما أبدأ في نقل التطويرات إلى الإصدار المستقر طويل الأمد الجديد (الذي يتداخل مع الإصدار المستقر طويل الأمد القديم)، هل سأحتاج إلى إنشاء فروع لكل إصدار وسيط؟
على سبيل المثال، الإصدار المستقر طويل الأمد الحالي هو 2026.1، والإصدار الحالي هو 2026.6، وأحدث إصدار هو 2026.7، لا يزال مدعومًا في 2026.5. عندما أقوم بنقل إضافتي إلى الإصدار المستقر طويل الأمد الجديد (2026.7)، بينما لا يزال Discourse يدعم الإصدار المستقر طويل الأمد القديم. هل سأحتاج إلى إنشاء الفروع التالية:
d-compat/2026.1d-compat/2026.2d-compat/2026.3d-compat/2026.4d-compat/2026.5d-compat/2026.6
حيث أن الإصدارات من .2 إلى .5 (بما في ذلك) قد انتهت دورة حياتها (EOL) في Discourse، لكن قد لا يزال بعض المستخدمين يستخدمونها.
أم أن Discourse يجد الفرع الأنسب إذا كان هناك فرع مفقود، بدلاً من افتراض الفرع الرئيسي؟
على سبيل المثال، إذا كنت أستخدم الإصدار 2026.5 وكانت الفروع الوحيدة المتاحة هي d-compat/2026.1 و d-compat/2026.6. أي فرع سيتم استخدامه؟
d-compat/2026.1لأنه أقرب إصدار متوافق؟mainلأنه لا يوجد فرع محدد؟