لمزيد من المعلومات حول جميع التغييرات التي تم إصدارها في الإصدار 2026.7، يرجى الاطلاع على:
تم أيضًا إصدار تحديثات تصحيحية للإصدارات الأخرى المدعومة:
لمزيد من المعلومات حول جميع التغييرات التي تم إصدارها في الإصدار 2026.7، يرجى الاطلاع على:
تم أيضًا إصدار تحديثات تصحيحية للإصدارات الأخرى المدعومة:
هل يصبح هذا الإصدار الحالي “esr” أم أنني أخطأت في فهم شيء؟
في الواقع، لا أستطيع فهم ما حدث. بالنسبة لهذا التحديث (الذي كان عاجلاً للغاية بسبب Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub)، كان يتطلب إعادة بناء، ولكن نظراً لوجود سجل تغييرات v2026.1.5 → v2026.1.6، افترضت أنه سيكون مجرد رفع طفيف في الإصدار. ولكن للأسف، الآن أنا على الإصدار v2026.7.0.据我所知، تم تكوين منتدائي ليكون على esr :
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "2048MB"
## can improve sorting performance, but adds memory usage per-connection
db_work_mem: "40MB"
## Reduce max upload size
upload_size: 1m
## Which Git revision should this container use? (default: tests-passed)
version: esr
كما فوجئت أيضاً برؤية مجموعة كاملة من استعلامات ما بعد التحديث مثل هذا:
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migrating ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: duration: 16903.716 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: duration: 15529.318 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: duration: 798.943 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: duration: 143.500 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: duration: 1051.872 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: duration: 658.965 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
نعم، هذا صحيح!
هذا الإصدار هو إصدار ESR جديد، لذا انتقلت إليه عند التحديث.
هل يمكن جعل هذا أقل إرباكًا في المستقبل؟ ربما يكون الأمر خاصًا بي فقط، ولكن إذا تم تطبيق تحديث على فرع ESR الذي أستخدمه حاليًا، فإنني أفترض أن ذلك لأن الإصدار الرئيسي الحالي لهذا الفرع لا يزال مدعومًا.
الإصدار 2026.1 لا يزال مدعومًا، ويمكنك تثبيت تثبيتك على هذا الإصدار عن طريق ضبط version: release/2026.1 في ملف app.yml الخاص بك. في هذه الحالة، كان إعادة البناء سيجلب تحديث الأمان على فرع 2026.1.
أعتقد أنك كنت تستخدم version: esr؟ في هذه الحالة، أنت تتبع أحدث إصدار من ‘esr’، وهو الآن 2026.7.
يمكنك العثور على معلومات حول فترات الدعم، والتداخلات بين دعم ESR، على https://releases.discourse.org/
للأسف، لا يمكن التراجع عن إصدار Discourse. ولكن إذا أردت تجنب ذلك في المستقبل، يمكنك التثبيت على release/2026.7 (وتأكد من تحديث هذا التثبيت يدويًا قبل أن ينتهي دعم 2026.7).
شكراً. أعتقد أنني أبحث عن الطريقة الأكثر أماناً/الأوتوماتيكية لضمان البقاء على أقدم إصدار لا يزال مدعوماً، أي أبطأ مسار للتطوير.
أنا أيضاً من نفس الرأي، وأعتقد أن esr (تقريباً) يفعل ذلك. كل بضع أشهر تظهر نسخة esr جديدة وتنتقل إليها، وهو ما حدث للتو. لكن في الواقع، لا تزال النسخة القديمة من esr مدعومة لمدة شهرين آخرين، لذلك كنت تتوقع أن تظل على النسخة السابقة من esr. (أعتقد أن هذا أمر معقول ترغب في القيام به. هل نحتاج إلى تسمية esr-maintained؟)
أعتقد أنه أمر معقول للنظر فيه، ولكن خذ بعين الاعتبار أيضًا… ما الذي سيكون مختلفًا بعد شهرين، بمجرد توقف دعم الإصدار v2026.1؟
بدون إجراء تغييرات إضافية، ستظل تتلقى التحديثات في ذلك الوقت “بدون إنذار مسبق”.
هل هذا مقبول؟
نعم، أعتقد أنه لا يزال من المنطقي الرغبة في التمسك بالإصدار المستقر الممتد (ESR) القديم لفترة أطول. فهذا يعني أن الإصدار المستقر الممتد الجديد قد خضع لبعض الاختبارات وقد يتضمن بعض الإصلاحات.
قمت بتحديث الإصدار المستقر الممتد الجديد خلال ساعة واحدة، وأندم على ذلك إلى حد ما: في الظروف الحالية، كان الأجدر بي تثبيت الإصدار السابق والالتزام به، والاعتماد فقط على إصلاحات الأمان. هذا يفصل بين إصلاح الأمان العاجل ومنحنى التعلم الإداري وأي أخطاء جديدة سيتم إصلاحها قريباً. انظر إلى الموضوع المفيد جداً:
الانتقال من الإصدار المستقر الممتد 2026.1 إلى 2026.7 - ما وجدته
(لماذا نتوقع وجود أخطاء جديدة في إصدار مستقر ممتد جديد؟ لأن،据ما أستطيع ملاحظته، كان الإصدار المستقر الممتد الجديد قيد التطوير المستمر حتى لحظة الإصدار. لا توجد مرحلة استقرار.)
هذه هي السؤال الكبير.
إذن، إذا كنت أستخدم esr-maintained، فبعد شهرين، سيكون esr وesr-maintained نفس الفرع، أليس كذلك؟ لذلك، بعد شهرين، سأظل مندهشًا من التغيير الكبير.
طالما أن esr وesr-maintained ليسا نفس الفرع، يمكن لـ Discourse إصدار/عرض تحذير بأنك دخلت في “فترة سماح ESR”. يمكن عرض هذا التحذير فقط على منتدي إداريي الموقع، وليس أثناء إعادة بناء الحاوية.
سيكون من الرائع الحصول على إشعار مسبق حول تبديل ESR، حتى تتمكن من التخطيط واختبار الترقية خلال هذه الفترة المدعومة من سماح.
في العالم المثالي، يمنحك هذا شهرين لتحديث خادم البيئة التجريبية (Staging) الخاص بك إلى الإصدار المستقر طويل الأمد الجديد (ESR)، بينما يمكنك في بيئة الإنتاج تشغيل الإصدار المستقر طويل الأمد القديم مع تحديثات الأمان لتغطية هذه الفترة.
إنه من المنطقي حقًا وجود نوع من تتبع التسميات البسيط لمتابعة الإصدار المستقر طويل الأمد القديم المُرقَّع، بحيث تحصل تلقائيًا على التحديثات المدعومة لذلك الإصدار القديم.
ربما يكون هناك بالفعل طريقة لتحقيق ذلك؟
لا أعتقد أن قناة ESR ستتلقى العديد من إصلاحات الأخطاء. تماماً مثل الإصدار 2026.1 - فهي ستتلقى فقط إصلاحات أمنية من الآن فصاعدًا.
لذا، في حين أنه من الممكن أن تصبح بعض هذه الأخطاء معروفة خلال شهر، إلا أن هذا لا يعني أنك لن تضطر إلى التعامل معها.
من منظور متشائم، سنرى! أتخيل أنه إذا تم العثور على تغيير كسر متوافق غبي في إصدار ESR جديد تمامًا، فسيتم إصلاحه. ربما لم يكن هذا العالم الجديد في مكانه لفترة كافية لرؤية ذلك يحدث. في الواقع، لا أتوقع إصلاحات للإزعاجات البسيطة.