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

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

  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 يدويًا كل شهر ليس مثاليًا حقًا، لذا نأمل أن نتمكن من تصميم نظام يجعل العملية أكثر سهولة للمستخدم.

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

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

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

5 إعجابات