أملك تثبيتًا مستضافًا ذاتيًا وتعمل الإضافات فيه بشكل صحيح، لكن Discourse يستمر في التحديث تلقائيًا دون إذن، ومؤخرًا تعطل المنتدى لأن إحدى الإضافات لم تعد متوافقة.
بما أن حالة الاستخدام الخاصة بي محددة بالفعل ولا أحتاج فعليًا إلى ميزات Discourse الجديدة، فكيف يمكنني تعطيل التحديثات حتى لا تتعطل الإضافات؟
لا يحدث Discourse تلقائيًا. نحن لا نملك حتى ميزة التحديث التلقائي.
هل يقوم شخص ما بتحديث منتدىك؟ أم أضفت مهمة خلفية يدوية للقيام بذلك على خادم المضيف؟
هذا مدهش، لأنني لا أملك أي إضافات تُجري تحديثات تلقائية، ولا أستطيع رؤية أي شيء في ملف app.yml، لكنك سبق أن ذكرت أن منصة Discourse لا تتوفر على هذه الميزة.
هل توجد طريقة لاستخراج اللحظة الدقيقة (التاريخ والوقت) التي تم فيها آخر تحديث لمنصة Discourse؟
حسناً، أفهم. يقول إنه تم آخر تحديث قبل 3 ساعات، وقبل 3 ساعات قمت بتشغيل:
./launcher rebuild app
هل يقوم هذا الأمر بتحديث Discourse؟ إذاً، كيف أقوم بتثبيت الإضافات دون تحديث Discourse؟
نعم، هذه هي الطريقة الرئيسية لتحديث Discourse.
إما أنك تقوم بتثبيت الإضافات أو أنك في حالة
بينما من الممكن تقنياً تثبيت Discourse على إصدار محدد أثناء تثبيت الإضافات، فإن ذلك يتطلب تحليلاً دقيقاً جداً لتوافق الإصدارات، حيث تفترض العديد من الإضافات أن نسخة Discourse محدثة.
من الناحية التقنية، من الممكن تثبيت Discourse على إصدار محدد أثناء تثبيت الإضافات
كيف يمكنني القيام بذلك؟
يتطلب ذلك تحليلاً دقيقاً جداً لتوافق الإصدارات، حيث تفترض العديد من الإضافات أنك تستخدم إصداراً محدثاً من Discourse
الإضافات هي من إعدادي، ولا أريد أن تتعطل، ولقد مررت بتجربة سيئة بالفعل عندما غيّر Discourse البنية أو أي شيء آخر. أتمنى أن يتبع المنتدى فلسفة Golang.
هل فكرت في التحويل إلى إصدار ESR بدلاً من تثبيت إصدار محدد؟ عندها ستظل تتلقى تصحيحات الأمان، ولكن ستضطر إلى التعامل مع التغييرات الأخرى كل 6 أشهر فقط.
هذا بداية جيدة، لكنني ما زلت أنتظر شخصًا يستطيع شرح كيفية البقاء على إصدار محدد.
لست متأكدًا تمامًا مما تنتظره. الموضوع الذي أشرت إليه يشرح بالفعل كيفية تثبيت الإصدار الذي تريده.
لقد قلت إنك لا تريد إصدار ESR، بل إصدارًا محددًا. لكن العملية نفسها تنطبق سواء كنت تستخدم فرعًا أو وسمًا أو معرف التزامن (commit hash) محددًا - فأنت ببساطة تستبدل قيمة version وفقًا لذلك. يمكنك أيضًا العثور على بعض الأمثلة لذلك في المنتدى [1] [2]
لا أزال أوصي بتجنب استخدام التزامنات (commits) المثبتة في بيئة الإنتاج، لأنك لن تتلقى تحديثات الأمان أو الإصلاحات إلا إذا قمت بتتبعها يدويًا.ولكن تلك مجرد مراجعات، بشكل أساسي، حول الفرع الذي أريد استخدامه. أنا أقول إنه يجب إصلاحه في إصدار معين مثل 2026.6.0 وعدم التحديث من ذلك الإصدار أبداً. ما تقترحه يتغير باستمرار بين الإصدارات، فقط على فرع مختلف.
لا يتغير الأمر حتى لو اخترت مرجعًا ثابتًا لا يتحرك:
ولكن تنطبق جميع التحذيرات المذكورة أعلاه — ولا يُنصح عمومًا بهذا الأسلوب.
اتخاذ هذا النهج (أو اتباع فرع إصدار محدد) يعني تحمل مسؤولية أكبر عن متابعة مواعيد توقف الدعم وإدارة هذه المخاطر وفقًا لذلك.
قلت إنك يمكنك وضع أي إصدار هناك. هل راجعت الأمثلة التي ربطت بها؟
متى تتوقع أن يتغير مثل هذا التجزئة الثابتة للالتزام؟
عذراً، خطئي، لم أقرأ ذلك الجزء. كيف يمكنني العثور على معرف الـ commit الطويل لتثبيتي الحالي؟
