RFC: استراتيجية إصدار جديدة لـ Discourse

[david (David Taylor)]

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

ستتطور هذه الوثيقة مع تلقينا للتعليقات، وبدء تنفيذ النظام، ثم توسيع استخدام تدفقات الإصدار الجديدة.

إذا كانت لديك أي تعليقات/اقتراحات في هذه المرحلة، فيرجى إخبارنا بالرد على هذا الموضوع!

---

الأهداف

1. تقديم “إصدارات” أكثر انتظامًا لـ Discourse، والتي توفر توازنًا بين سرعة التطوير والاستقرار.

2. الاستمرار في تقديم إصدارات كل 6 أشهر تقريبًا، والتي يتم دعمها لفترة طويلة.

3. توفير دعم متداخل للإصدارات العادية وإصدارات الدعم الممتد، بحيث يتمتع المسؤولون بمزيد من المرونة في توقيت التحديثات، مع الاستمرار في تلقي تحديثات الأمان الهامة.

4. الحفاظ على الحد الأدنى من المراسم حول “الإصدارات”. يجب أن يتم أتمتة أكبر قدر ممكن، ولا يجب أن يبطئ تجربة المطور الأساسية. إصدارات ESR هي نفسها أي إصدار آخر.

5. يجب أن تتطابق التسمية والإجراءات مع معايير الصناعة، بحيث يسهل شرحها للمطورين والمستخدمين النهائيين.

نظرة عامة عالية المستوى

• إصدار تقريبي لإصدار واحد شهريًا. الإصدار “الرئيسي” هو السنة الحالية، ويتزايد الإصدار “الفرعي” مع كل إصدار. سيتم زيادة رقم إصدار التصحيح لأي إصلاحات يتم إرجاعها.

  على سبيل المثال، سيكون الإصدار الأول من عام 2026 هو v2026.0، والإصدار التالي سيكون v2026.1، وما إلى ذلك.

  ستتلقى الإصدارات إصلاحات هامة لدورتي إصدار كاملتين. على سبيل المثال، سيستمر دعم 2026.0 حتى يتم إصدار 2026.2.

• كل 6 أشهر تقريبًا، يتم الإعلان عن أحد هذه الإصدارات كإصدار دعم ممتد (ESR). تظل إصدارات ESR مدعومة لمدة إصدارين بعد الإعلان عن ESR التالي.

  على سبيل المثال، إذا كان v2026.0 هو ESR، وكان v2026.6 هو ESR التالي، فسينتهي دعم v2026.0 عند إصدار v2026.8. بافتراض وتيرة شهرية، سيكون ذلك تداخلًا لمدة شهرين في دعم ESR.

• توفير إصلاحات هامة لـ latest، والإصدار الأخير، والإصدار السابق، وأي إصدارات ESR نشطة.

• إعادة تسمية الفرع tests-passed إلى latest.

مثال على رسم بياني لفترات الدعم على مدار عام:

gantt
    title فترات إصدار ودعم Discourse (يناير 2026 - يناير 2027)
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    2026.0 (ESR) :active, 2026-01-27, 2026-09-29
    2026.1 :done, 2026-02-24, 2026-04-28
    2026.2 :done, 2026-03-31, 2026-05-26
    2026.3 :done, 2026-04-28, 2026-06-30
    2026.4 :done, 2026-05-26, 2026-07-28
    2026.5 :done, 2026-06-30, 2026-08-25
    2026.6 (ESR) :active, 2026-07-28, 2027-01-26
    2026.7 :done, 2026-08-25, 2026-10-27
    2026.8 :done, 2026-09-29, 2026-11-24
    2026.9 :done, 2026-10-27, 2026-12-29
    2026.10 :done, 2026-11-24, 2027-01-26
    2026.11 :done, 2026-12-29, 2027-01-26

التنفيذ

• سيكون لكل إصدار فرع مقطوع من latest. سيتم تسميتها، وسيتم الاحتفاظ بها إلى أجل غير مسمى. على سبيل المثال، سيكون لـ v2026.1 فرع يسمى release/2026.1.

• سيتم وضع علامة على كل إصدار تصحيح. على سبيل المثال، v2026.1.0، v2026.1.1، إلخ.

• سيتم تسمية أحدث إصدار release. سيتم تسمية أحدث ESR esr.

• سيتم تسمية الإصدار السابق release-previous. سيتم تسمية ESR النشط السابق (إن وجد) esr-previous.

• للتوافق مع الإصدارات السابقة، سيتم ربط العلامات التي تطابق تدفقات الإصدار الحالية بأقرب ما يعادلها الجديد. stable → esr. beta → release. tests-passed → latest.

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

• على latest، سيكون رقم الإصدار هو الإصدار قيد التطوير حاليًا، متبوعًا بـ -latest. على سبيل المثال، 2026.3.0-latest.

عملية الإصدار الآلي

كل شهر، سيفتح إجراء GitHub طلب سحب جديد يحتوي على التزام واحد يقوم بترقية version.rb على main إلى الإصدار التالي -latest.

بمجرد أن يقوم شخص بدمج طلب السحب، سيكتشف إجراء GitHub آخر انتقال main إلى الإصدار التالي -latest ويقطع فرعًا للإصدار المكتمل. في الأساس، سيصبح هذا الفرع “مرشحًا للإصدار”. سيتم فتح طلب سحب آلي آخر مقابل فرع الإصدار بتحديث لإزالة اللاحقة -latest من version.rb، وبالتالي “إصداره”.

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

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       checkout main
       commit id:'version v2026.1-latest'
       commit id:'...'
       commit id:'....'
       branch 'release/2026.1'
       commit id:'version 2026.1'
       checkout 'main'
       commit id:'version v2026.2-latest'

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

ستقوم كل هذه الأتمتة تلقائيًا بتحديث العلامات المختلفة (release، release-previous، esr، esr-previous، بالإضافة إلى اختصارات التوافق مع الإصدارات السابقة) بشكل محدث.

إصلاحات الأمان

تظل سير عمل إصلاح الأمان كما هي إلى حد كبير، باستثناء أننا نحتاج الآن إلى إجراء الإصلاحات في اثنين من هذه الأماكن الثلاثة الجديدة:

• latest

• esr

• esr-previous

• release

• release-previous

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

عند إدخال إصلاح أمني إلى latest، سيتم نقل علامة latest-security-fix تلقائيًا إلى هذا الالتزام. سيتم تحديث docker_manager لمراقبة هذه العلامة وحث المسؤولين على التحديث. هذا يسمح لنا بإصدار وإخطار إصلاحات الأمان دون الحاجة إلى تسريع زيادة الإصدار.

الترجمات

في الوقت الحالي، يمكن ترجمة فروع stable و tests-passed في CrowdIn، ويتم دمج النتائج بانتظام. في النظام الجديد، نخطط في البداية لترجمة latest و release في CrowdIn.

من الناحية المثالية، بحلول الوقت الذي يصبح فيه release release-previous أو esr، ستكون الترجمات قد استقرت. إذا كان هناك طلب على الترجمات المستمرة لتلك الإصدارات، فهذا شيء يمكن النظر فيه في المستقبل.

توافق الإضافات/السمات

سيؤدي زيادة استخدام تدفقات Discourse غير latest إلى زيادة اعتمادنا على نظام discourse-compatibility. لذلك نحتاج إلى بعض التحسينات لنظام التوافق.

بدلاً من استخدام ملف .discourse-compatibility على main، يمكننا بدلاً من ذلك دعم التوافق الضمني بناءً على فروع/علامات مسماة خصيصًا. سيكون هذا أسهل بكثير من التعامل مع تجزئات الالتزام يدويًا. على سبيل المثال، يمكن أن تحتوي الإضافة على فروع مثل

• d-compat/v2026.1
• d-compat/v2026.2
• d-compat/v2026.3
• main (يستخدم لأي إصدار Discourse لا يحتوي على فرع خاص به)

عند تثبيت إضافة، يمكن لـ Discourse التحقق من وجود فرع يطابق الإصدار الحالي. إذا كان موجودًا، فقم بسحبه. بخلاف ذلك، تحقق من ملف .discourse-compatibility. بخلاف ذلك، قم بسحب الفرع الافتراضي.

يمكننا إنشاء إجراء GitHub عام يعمل على كل سمة/إضافة يوميًا، ويتحقق من إصدارات Discourse الجديدة، وينشئ هذه الفروع تلقائيًا. يمكن لكل سمة/إضافة اختيار استخدام هذا الإجراء التثبيت التلقائي، أو يمكنها اتباع استراتيجية “عائمة” أكثر.

استضافة discourse.org

مبدئيًا، سيستمر عرضنا المستضاف في تشغيل أحدث إصدار من Discourse. في المستقبل، سنستكشف خيارات لعملائنا من فئة المؤسسات لاختيار إصدار “release”.

إعدادات التثبيت القياسية

مبدئيًا، سيظل الإعداد الافتراضي هو latest. سيتمكن المسؤولون من الاشتراك في تدفق الإصدار الجديد بنفس الطريقة التي يشتركون بها في stable حاليًا. قد نستكشف تبديلات أسهل بين تدفقات الإصدار في المستقبل، بمجرد أن يصبح النظام أكثر نضجًا.

[NateDhaliwal]

@david

beta → release

@david

على سبيل المثال، سيكون لـ v2026.1 فرع باسم release/2026.1

أنا مرتبك بعض الشيء. إذن tests-passed المعروف أيضًا باسم latest (والذي أفترض أنه الافتراضي) سيكون الأكثر تحديثًا (يحصل على التحديثات الأكثر تكرارًا؛ لا تغيير هناك)، ولكن الفرع beta الحالي، وهو الآن الفرع release، سيظل يتصرف كما هو الآن، أي “مجموعة” من الالتزامات/التحديثات، ثم سيكون الفرع ESR (المعروف أيضًا باسم stable) “مجموعة” أكبر من تحديثات beta/release؟

@david

سيتم تمييز أحدث إصدار بـ release. سيتم تمييز أحدث ESR بـ esr.

هل هذا يعني أن release يصبح الآن الخيار الافتراضي، أم عندما تقول “أحدث إصدار” فإنك تشير إلى “أحدث تحديث على فرع release؟” هل سيكون هناك فرق بين ذلك و latest؟

شكرًا!

[david (David Taylor)]

@NateDhaliwal

ولكن الفرع beta الحالي، والآن الفرع release سيظل يتصرف كما هو الآن

beta هو حاليًا علامة (tag)، ولا يتلقى أي إصلاحات مراجعة للخلف.

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

سيكون release علامة تتبع أحدث إصدار (بما في ذلك إصدارات التصحيح) للإصلاحات الأمنية.

@NateDhaliwal

هل هذا يعني أن release سيصبح الآن الخيار الافتراضي

لا:

@david

مبدئيًا، سيظل الافتراضي هو latest. سيتمكن المسؤولون من الاشتراك في تدفق الإصدار الجديد بنفس الطريقة التي يشتركون بها في stable في الوقت الحالي. قد نستكشف تبديلات أسهل بين تدفقات الإصدار في المستقبل، بمجرد أن يصبح النظام أكثر نضجًا.

@NateDhaliwal

عندما تقول “أحدث إصدار” هل تشير إلى "أحدث تحديث على الفرع release؟ هل سيكون هناك فرق بين ذلك و latest؟

“أحدث إصدار” (أو ببساطة “release”) = أحدث تثبيت على أحدث فرع إصدار

“latest” = الاسم الجديد لـ tests-passed

[NateDhaliwal]

شكراً، هذا يوضح الأمر!

[Ed_S]

هذا يبدو تطورًا إيجابيًا!

هل سيكون هناك أي اختبارات محددة للترقيات من esr-previous إلى esr في الوقت الذي يتم فيه تسمية esr؟ أرى أن مثل هذه الترقيات يجب أن تكون ترقيات سلسة، أو أن يكون لها أوصاف جيدة لكيفية أدائها بسلاسة قدر الإمكان.

[david (David Taylor)]

نعم، ستظل الترقيات بين إصدارات ESR (أو أي إصدار مدعوم) سلسة.

[itsbhanusharma (Bhanu Sharma)]

طلب بسيط فقط من أجل الراحة، هل يمكن ربط المؤشر (على سبيل المثال 2026.0) بالشهر الذي يتم فيه دفع الإصدار؟ (أي 2026.01 لشهر يناير، 2026.02 لشهر فبراير وما إلى ذلك)

[david (David Taylor)]

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

[itsbhanusharma (Bhanu Sharma)]

مشروع أستخدمه بكثافة (mailcow) يتخطى الشهر عندما لا يكون هناك تغيير كبير في النواة.

والعد من 0 سيكون غريبًا حقًا. إنه منطقي تمامًا للمبرمجين ولكن ليس له معنى كبير للأشخاص غير التقنيين.

[pfaffman (Jay Pfaffman)]

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

@david

المشكلة في ربط الأشياء صراحةً بشهر هي أننا لن نتمكن من تخطي شهر

أوبونتو لديها YY.04 و YY.10. لقد نجحت لمدة عشرين عامًا. لا يبدو تخطي الأشهر صعبًا.

@david

أو إصدار نسختين في شهر واحد

يبدو هذا مشكلة أكبر، على الرغم من أنه يمكنك فعل شيء مثل 22.1a أو 22.01a إذا كان عليك إصدار نسختين في شهر واحد.

[tvavrda (Tomas Vavrda)]

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

نحن نستخدم إصدارات شهرية. لذا هناك 1-12. الإيقاع يساعد الجميع. هناك دائمًا شيء ما لإصداره ولا أحد يريد قص الفرع مرتين في الشهر على أي حال. أيضًا عندما أقول “أستخدم 2025.6” يعرف الجميع أنه الإصدار الذي كان قبل العطلة الصيفية.

[RGJ (Richard - Communiteq)]

أولاً، هذه خطوة رائعة!

بعد التفكير في الأمر، لدي ملاحظتان بسيطتان.

1. git branch والعديد من الأدوات الأخرى لا تفهم ترقيم الإصدارات وستقوم بالفرز أبجديًا أو رقميًا. في كلتا الحالتين، سينتهي الأمر بـ 2026.10 بين 2026.1 و 2026.2. مستوحاة من Ubuntu، أقترح إدخال صفر بادئ للإصدارات وإصدارات التصحيح عندما تكون مكونة من رقم واحد فقط، لذلك سيكون لدينا v2026.01، v2026.02 و v2026.10 وبعد ذلك سيكون الكون سعيدًا مرة أخرى.

2. طريقة توافق المكونات الإضافية الجديدة تبدو معقدة للغاية وهشة

@david

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

• d-compat/v2026.1
• d-compat/v2026.2
• d-compat/v2026.3
• main (يستخدم لأي إصدار Discourse لا يحتوي على فرع خاص به)

عند تثبيت مكون إضافي، يمكن لـ Discourse التحقق من وجود فرع يطابق الإصدار الحالي. إذا كان موجودًا، قم بالتحقق منه. بخلاف ذلك، تحقق من ملف .discourse-compatibility. بخلاف ذلك، قم بالتحقق من الفرع الافتراضي.

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

لذلك لن أستخدم هذا أبدًا وسأستمر في استخدام .discourse-compatibility بدلاً من ذلك.

[david (David Taylor)]

@RGJ

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

القصد هو العكس. فروع التوافق مخصصة فقط للفروع “المُصدرة” من Discourse. سيستخدم Discourse latest دائمًا main الخاص بإضافتك. هناك ستطور الميزات الجديدة.

لذا، ستكون القصة كالتالي:

يقوم Discourse بإصدار v2026.2. تقوم إجراءات GitHub على إضافتك تلقائيًا باكتشاف ذلك وتقوم بإنشاء فرع d-compat/v2026.2. الآن، أي شخص يستخدم Discourse v2026.2 سيستخدم إصدار d-compat/v2026.2 من إضافتك.

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

ثم، أثناء احتسائك لكأسك الثالث من النبيذ ، يقوم Discourse بإنشاء v2026.3. في البداية، لا يوجد فرع إضافة لهذا الإصدار، لذلك سيتم استخدام main. تستمر الأمور في العمل كما كانت عليه بالنسبة للأشخاص على latest.

في غضون ساعات، تكتشف إجراءات GitHub الخاصة بك الإصدار الجديد وتقوم بتجميد d-compat/v2026.3، جاهزًا لهبوط ميزة إضافتك التالية على main دون مخاوف بشأن التوافق مع الإصدارات السابقة.

هذه هي في الأساس سير العمل التي نستخدمها في CDCK للتعامل مع التوافق المستقر للسمات/الإضافات. بعد كل إصدار مستقر، لدينا نص برمجي لتشغيل مئات السمات/الإضافات الخاصة بنا وتجميدها عبر .discourse-compatibility. يهدف هذا الاقتراح القائم على الفروع إلى أن يكون نسخة أخف من سير العمل هذا.

[RGJ (Richard - Communiteq)]

هذا رائع، شكراً لك على الشرح المفصل.
يبدو أنه يمكنني تناول كأس رابع من النبيذ

[schneeland]

أؤيد ما قاله الآخرون، أنا أحب اتجاه التغييرات المقترحة. وأعتقد أن أسماء الفروع المقترحة أكثر بديهية من الأسماء القديمة

ما ليس واضحًا تمامًا بالنسبة لي بعد هو كيف ستعمل عملية الترقية لفروع release و esr (يبدو أن latest مباشر). تذكر أنه في كل نقطة زمنية، سيتم دعم كل من الإصدار الحالي (لنسميه n) والإصدار السابق (n-1)، وأنه بصفتي مسؤولاً، سيكون لدي خيار بشأن وقت الترقية.

الآن بناءً على تجربتي مع البرامج الأخرى، عندما يصل إصدار جديد (n+1)، سأُخطَر بتوفر الإصدار n+1. ويمكنني بعد ذلك أن أقرر إجراء ترقية رئيسية (مكافئة لـ apt dist-upgrade على سبيل المثال في لينكس) أو إجراء تحديث بسيط/قياسي (مكافئ لـ apt upgrade على سبيل المثال في لينكس) والبقاء على الإصدار n. هل هذا شيء سيتم تضمينه في البرنامج النصي لمشغل Discourse؟

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

أخيرًا، أتساءل عما إذا كانت الإصدارات الشهرية “سريعة جدًا” بالفعل. هذا بالطبع ذاتي أيضًا، ولكن بالنظر إلى تجربتي الخاصة في إدارة أشياء تكنولوجيا المعلومات بشكل جانبي كمتطوع، قد لا يكون لدي وقت للتحديثات الكبيرة كل شهر. وبناءً على ذلك، كنت أتساءل عما إذا كان بإمكانك أيضًا جعل حياتك كمطورين لـ Discourse أسهل قليلاً عن طريق إصدار ربع سنوي ببساطة، وعدم وجود فروع esr منفصلة، ولكن فروع release فقط.

[RGJ (Richard - Communiteq)]

@schneeland

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

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

[schneeland]

@RGJ

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

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

[RGJ (Richard - Communiteq)]

لا يتعلق الأمر بموعد قيام مؤلف السمة/الإضافة بنشر إصلاح، بل يتعلق بموعد قيام نواة Discourse بإصلاح أمني.

وفقًا لـ

@david

كل 6 أشهر تقريبًا، يتم الإعلان عن أحد هذه الإصدارات كإصدار دعم ممتد (ESR). تظل إصدارات ESR مدعومة لمدة إصدارين بعد الإعلان عن إصدار ESR التالي.

الاختلاف الوحيد بين release و esr هو أن esr يحصل على إصلاحات أمنية لمدة 6 + 2 = 8 أشهر.

[david (David Taylor)]

@schneeland

ما ليس واضحًا تمامًا بالنسبة لي حتى الآن هو كيف ستعمل عملية الترقية لفروع release و esr (يبدو أن latest مباشر).

باستخدام أدوات المشغل الحالية، وهيكل الفروع الجديد هذا، يمكنك التحكم في توقيت الترقية عن طريق القيام بشيء مثل:

1. إصدار v2026.02
2. تقوم بتعيين version: release/v2026.02 في ملف app.yml الخاص بك
3. إصدار v2026.03
4. تقوم بإعادة البناء. لا تزال تحصل على 2026.02، مع أي إصلاحات أمنية حديثة
5. عندما تكون جاهزًا، تقوم بالتبديل إلى version: release/v2026.03 في app.yml

ولكن تعديل ملف app.yml يدويًا كل شهر ليس مثاليًا حقًا، لذا نأمل أن نتمكن من تصميم نظام يجعل العملية أكثر سهولة للمستخدم.

@schneeland

حدسي هو أن كلا الإصدارين العادي و ESR سيحصلان على اختبار إضافي على الأقل.

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

@schneeland

أخيرًا، أتساءل عما إذا كانت الإصدارات الشهرية سريعة جدًا بالفعل.

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

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

[david (David Taylor)]

@schneeland

كان فهمي بناءً على المشاركات السابقة هو أن إنشاء فرع إصدار النسخة سيؤدي تلقائيًا إلى إنشاء فرع للمكون الإضافي لهذا الإصدار

الأمر متروك لمؤلف المكون الإضافي/السمة هنا. إما أنهم يمكنهم المتابعة بالاستراتيجية الحالية، حيث يحتاج الفرع main للمكون الإضافي إلى العمل مع جميع الإصدارات “المُصدرة” من Discourse. أو يمكنهم استخدام استراتيجية التفريع التلقائي، مما يسهل التوافق، ولكنه يعني أيضًا أنك قد تحتاج إلى القيام بالكثير من “النقل الرجعي” في المكون الإضافي الخاص بك في حالة وجود أي إصلاحات حرجة للأخطاء/الأمان.

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