لمزيد من المعلومات حول جميع التغييرات التي تم إصدارها في 2026.1، تحقق من:
هذا هو أول إصدار “ESR” (دعم طويل الأمد) لـ Discourse، ويحل محل الفرع القديم “stable” (مستقر). سيتم ترقية المواقع التي تتبع المستقر من 3.5 إلى 2026.1 عند الترقية التالية. للاطلاع على جميع التغييرات من 3.5 إلى 2026.1، استخدم هذا الرابط.
تم إصدار إصدارات التصحيح للإصدارات الأخرى المدعومة أيضًا:
2026.1.0 هو أيضًا أول إصدار esr.
بالنسبة للأشخاص الذين يستخدمون الفرع stable الموجود سابقًا (والذي تم تسميته الآن esr)، سينتقلون من 3.5.3 إلى 2026.1.0؛ وليس 3.5.4
دعني أرى، لدي حتى أبريل لعدم التحديث (3 أشهر) عندما يتم إهمال v2026.1، سيكون إصداري الحالي هو ESR، أليس كذلك؟ كل هذه التغييرات مربكة بعض الشيء.
نعم، ما لم يكونوا يستخدمون الوسم v3.5.4 للإبقاء على الإصدار 3.5.
الرسم التخطيطي الموجود في الصفحة الرئيسية لـ https://releases.discourse.org/ هو أفضل طريقة لتصور الأمور.
بغض النظر عن مسار الإصدار الذي تختاره، ستحتاج دائمًا إلى التحديث بانتظام للحصول على إصلاحات أمنية حرجة. السؤال هو ما إذا كنت تريد أيضًا جلب ميزات جديدة وتغييرات أخرى جنبًا إلى جنب مع الإصلاحات الأمنية (إذا كان الأمر كذلك، استخدم release أو latest)، أو ما إذا كنت تفضل الحصول على وتيرة كل 6 أشهر تقريبًا لذلك (إذا كان الأمر كذلك، استخدم esr).
لا يزال هذا المخطط الجديد للترقيم في أيامه الأولى، لذا ستستمر الوثائق والأدوات في التطور مع نمونا في النظام الجديد.
كانت الإصدار v2026.0 عندما قمت بالتحديث آخر مرة في ديسمبر والآن v2026.2، وستصبح إصدار دعم طويل الأمد (ESR) في أبريل، أليس كذلك؟
راجع الصفحة الرئيسية لـ releases.discourse.org للحصول على جميع معلومات الدعم. 2026.1 هو إصدار الدعم الممتد الحالي، وسيتم دعمه حتى أكتوبر 2026.
سيتم إصدار 2026.2 في فبراير، وسيستقبل إصلاحات أمنية لمدة شهرين بعد ذلك. لن يكون إصدار دعم ممتد.
هل الإصدار 2026.1.0 هو أول إصدار مستقر/ESR يقوم بـ إسقاط دعم نظام iOS والمتصفحات القديمة الأخرى؟ هذا تغيير كبير بما يكفي بحيث يجب إدراجه في مكان ما في ملاحظات الإصدار. لم أتمكن من العثور على أي شيء عنه في مربع البحث “التغييرات التفصيلية” في النهاية على الرغم من ذلك.
أوه، أعتقد أن السبب هو أنك ربطت بسجل التغييرات للإصدار v2026.1.0-latest ← v2026.1.0. إذا قمت بتغييره إلى v3.5.3 → v2026.1.0 فإنه يعرض 2397 تغييرًا مفصلاً، بدلاً من 369 فقط. بالنسبة لإصدارات ESR هذه، يجب عليك حقًا الربط بآخر إصدار ESR بدلاً من -latest (هل هذا مثل RC؟)
ما زلت لا أستطيع رؤية التغيير الذي أشار بوضوح إلى إسقاط دعم المتصفحات القديمة، ولكن يمكنني العثور على هذا التغيير على الأقل: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
نعم 
بالتأكيد. الغالبية العظمى من الناس يستخدمون مسارات latest أو release الخاصة بـ Discourse، ولهذا السبب تم تحسين موقع سجل التغييرات لذلك. الأشخاص الذين يختارون ESR “يتخطون 5 إصدارات” في كل مرة يقومون فيها بالترقية، لذلك ستحتاج إلى النظر في التغييرات لكل من تلك الإصدارات الوسيطة.
يمكنك القيام بذلك عن طريق تصفح سجل التغييرات لكل إصدار وسيط، أو يمكنك استخدام المرشحات (الفلاتر) لإنشاء سجل تغييرات مخصص يغطي النطاق الكامل (كما فعلت). ربما يمكننا تحسين تجربة المستخدم لموقع الإصدارات ليكون بها نوع من الرابط السريع للقفز إلى مقارنة ESR → ESR.
بالنظر إلى آخر إصدار “مستقر”، لم يكن لدينا “سجل تغييرات ضخم” لذلك أيضًا. كان على الناس قراءة سجلات التغييرات لكل إصدار تجريبي وسيط للحصول على صورة كاملة للتغييرات. لذلك أعتقد أننا نسير في الاتجاه الصحيح هنا - على الأقل أصبح من الممكن الآن رؤية سجل تغييرات كامل، حتى لو لم تكن تجربة المستخدم سلسة تمامًا.
في الوقت الحالي، أضفت رابطًا لمقارنة ESR → ESR هذه في المنشور الأصلي هنا:
شكرًا على الملاحظات!
سواء كان ذلك من إصدار معين إلى آخر أو من نقطة عشوائية في latest إلى أحدث latest، إذا تعذر تطبيق تغيير بين الالتزامين x و y بواسطة المحدِّث المدمج، مما يتطلب بدلاً من ذلك إعادة بناء الحاوية من صورة جديدة، فهل سيحدد نظام ملاحظات الإصدار الجديد ذلك ويدون الحاجة إلى إعادة بناء؟
بشكل منفصل، هل سيمنع المحدِّث المدمج التحديث، ويطلب إعادة بناء؟
فهمي العام للمحدِّث المدمج هو أنه بعد تحديث Docker_manager، سيمنع تحديث Discourse إذا كانت هناك حاجة لإعادة بناء. لم أر هذا موثقًا رسميًا، ومن خلال التجربة لم يبدُ موثوقًا به تمامًا.
على وجه التحديد، في بعض الأحيان يؤدي التنقل من تحديث Docker_manager المكتمل إلى صفحة الإصدارات إلى توفر تحديث Discourse للبدء، ثم فقط بعد تحديث الصفحة سيتم حظره. [سأشير إلى أن آخر مرة رأيت فيها ذلك حدث كانت منذ وقت طويل، ربما تم إصلاحه.]
تتعلق الحاجة إلى إعادة بناء بـ “صورة قاعدة دوكر” (Docker base image) الخاصة بـ Discourse، والتي هي منفصلة تمامًا عن رقم إصدار Discourse. نحن نحتاجها عندما تكون هناك تغييرات حرجة في التبعيات على مستوى نظام التشغيل داخل صورة دوكر.
لذا سيكون من الصعب تضمينها في ملاحظات إصدار Discourse الأساسي. لكني أتفهم إحباطك وعدم قدرتك على التحديث من واجهة المستخدم. ربما يمكننا إجراء تحسينات على واجهة المستخدم في هذا الشأن.
يمكنني أن أتخيل أن هذا سيعمل عن طريق:
ومع ذلك، لا يزال لدينا بعض الأمور الأخرى الأكثر أهمية للعمل عليها حاليًا فيما يتعلق بعمل الإصدارات بشكل عام (على سبيل المثال، مشكلة توافق مكونات/إضافات السمة).
أوه، أعتقد أنه لا بأس في عدم القدرة دائمًا على استخدام واجهة المستخدم للتحديث، ويجب (وينبغي) أن يكون لدى أي شخص (فرد، عمل تجاري، أو غير ذلك) يستضيف Discourse بنفسه شخص متاح لديه مهارات مسؤول خادم أساسية على الأقل ليتمكن من أداء مهام مثل الحفاظ على تحديث نظام المضيف وإعادة بناء Discourse.
أهم الأشياء في ذهني هي:
طالما أن واجهة المستخدم يتم تحديثها دائمًا بشكل صحيح بعد تحديث Docker_manager، أي لا يمكن أن تنتهي في حالة تعرف فيها أن Docker_manager محدث ولكنه لا يعرف أن إعادة البناء مطلوبة، أعتقد أن كلا الأمرين صحيحان بالفعل.