ما يجب معرفته قبل الترقية من v3.4.0 إلى v2026.7.2

أنا المسؤول عن تثبيت Discourse المعتمد على Docker ويعمل على Ubuntu، وقد ورثته كجزء من مشروع مفتوح المصدر. على مدى سنوات، كنت أقوم بتحديثه عبر الأمر git pull && ./launcher rebuild app ثم من خلال واجهة الإدارة في /admin/update. ومع ذلك، توقفت عن التحديث بهذه الطريقة الخفيفة بعد تجربة مؤلمة خلال تحديث كاسر (breaking upgrade) بسبب docker_manager في يناير 2024 (انظر التعليقات على الالتزام هنا، والالتزام المُعاد هنا).

مرّت 2.5 سنوات منذ ذلك الحين، وأحتاج إلى استعادة إيقاع التحديث، لكنني ما زلت أشعر بقليل من التوتر بسبب التحديث المكسور الأخير. ما أودّ المساعدة في فهمه هو ما الذي يجب أن أعرفه قبل محاولة التحديث من الإصدار v3.4.0 إلى الإصدار v2026.7.2. موقعنا لا يستخدم أي إضافات إضافية، والتركيب الخاص الوحيد الذي أعلم به هو أننا نستخدم رابط Discourse Connect للحصول على تسجيل الدخول الموحد (SSO) مع موقعنا الرئيسي للمجتمع.

هل الأمر بسيط إلى هذا الحد؟

cd /var/discourse
git pull
./launcher rebuild app

ثم التحديث عبر واجهة الإدارة؟ هل هناك أي خطوات وسيطة يجب أن أكون على دراية بها عند الانتقال من v3.4.0 إلى v2026.7.2؟

شكرًا لكم،

كوري

أو … (بما أنك قلق) … خذ نسخة احتياطية (في أي حال) وقم بإعداد خادم جديد بالكامل واستعادة النسخة الاحتياطية عليه، ثم أعد توجيه النطاق إلى الخادم الجديد بعد الانتهاء.

الشيء الكبير الذي ستواجهه هو وجود ترقية كبيرة لـ Postgres (إلى الإصدار 18). إذا قمت ببناء خادم جديد، فلن تضطر للتعامل مع عملية الترقية هذه.

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

القلق هو سبب لجوء مديسي أنظمة Discourse ذوي الخبرة إلى إعداد بخادمتين (two container setup) حتى تتمكن من بدء تحديثات النظام قبل التأكيد عليها (على الرغم من أن ذلك لن يساعد كثيرًا عندما يكون لديك ترقية كبيرة لـ Postgres، لكنها تحدث نادرًا).

شكرًا لك على ردّك. أعجبني هذا الاقتراح وسأحاول السير في هذا المسار!

حاولتُ إجراء الترحيل (Migration) اليوم، واجهتُ مرة أخرى تغييرًا كاسرًا (Breaking Change) فورًا في الفرع الرئيسي (main) لـ discourse_docker:

هذا الالتزام (Commit) يُسبب فشل عمليات البناء (Builds) ويُكسر عملية التثبيت/الإعداد، ومع ذلك تم دمجه في الفرع الرئيسي على أي حال. هذا بالضبط ما كنتُ قلقًا بشأنه.

عند تشغيل الأمر ./launcher bootstrap app، يظهر ما يلي:

rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean?  assets:precompile

كيف يمكن لتغييرات كاسرة كهذه أن تُدمج في الفرع الرئيسي الذي يُقدَّم كجزء من تعليمات التثبيت الرسمية؟ هل يتم تجاهل أخطاء البناء؟ الخطأ نفسه الذي أراه موجود بوضوح في سجل الفشل:

تمكنتُ من الخروج (Checkout) إلى التزام سابق مكنني من المتابعة في خطوات الترحيل، لكنني الآن أشهد على حالتين من أصل حالتين حيث كانت عمليات الترقية مكسورة بسبب دمج التزامات غير مُختبرة في الفرع الرئيسي.

مرحبًا @corywright، نعتذر عن ذلك - الإصدار الحالي من ESR لا يحتوي على المهمة، وهناك تصحيح قيد التنفيذ هنا.

سنقوم بإصلاح الأمر قريبًا، وسأتأكد من إضافة هدف ESR كهدف لاختبار الدخان (Smoke Test) لمنع حدوث أي تراجع مستقبلي.

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