لقد أصبح تثبيت Discourse الخاص بي قديمًا (3.2.0.beta4-dev) وأحتاج إلى الترقية إلى 3.5. أخشى أن أزعج الأمور وأستخدم عددًا قليلاً من الإضافات/التكاملات التي لم أرغب في تغييرها (WP Discourse، وتسجيل الدخول عبر Wordpress بمعلومات العضوية وإضافة Category Lockdown) وقد واجهت مشاكل في الترقية اليدوية في الماضي.
ما هو أفضل نهج للقيام بالترقية؟ هل يجب أن أقوم بنوع من الترقية الجزئية إلى إصدار مختلف أولاً؟ هل هناك أي مشاكل يجب أن أكون على علم بها؟
قم بنشر منتدى تجريبي. لم أقم بعمل fork لأي شيء من قبل
إذا كنت تريد أن تكون الأكثر أمانًا، فستقوم بتشغيل خادم جديد، نقل موقع Discourse إلى VPS آخر باستخدام rsync (سأتخطى ملفات قاعدة البيانات)، واستعادة نسخة احتياطية.
أنا متأكد من أنك ستحتاج إلى تحديث PostgreSQL 15.
لا ينبغي أن تكون هناك مشكلات مع WP Discourse. يمكنك التحقق من Discourse Category Lockdown.
هناك فرصة جيدة جدًا يمكنك فقط اتباع ترقية PG 15 وسيكون كل شيء على ما يرام، ولكنك سألت عن “أفضل الممارسات”.
هذا له بعض الآثار الجانبية الجيدة، وهي ضمان حصولك على نسخة احتياطية حديثة وأن لديك نسخة آمنة من تلك النسخة الاحتياطية. تحتاج إلى القيام بهذه الأشياء، بغض النظر عن كيفية إجراء الترقية الخاصة بك.
لدي انطباع بأنه من الممارسات الجيدة إلغاء التعليق على جميع الإضافات الخاصة بك أيضًا، ولكن سيكون من الجيد أن يؤكد شخص ما ذلك.
نعم. في الواقع، معرفة أنه يمكنك تشغيل خادم جديد واستعادة نسخة احتياطية. اضطررت للقيام بذلك مرة واحدة مؤخرًا عندما تعطلت وحدة تخزين SSD في أحد خوادمي. تمنيت لو أنني تدربت بالفعل (على الرغم من أنه تبين، على الرغم من أنني لم أتدرب بشكل صريح، إلا أن المرور بالعملية مئات المرات كان كافيًا وتم كل شيء كما هو مخطط له).
لا يوجد أي سلبيات، خاصة وأن مجموعة من المكونات الإضافية تم نقلها إلى النواة وقد يكون هناك شيء قديم معطل. بعد أن يصبح الشيء في حالة عمل، يمكنك استعادة أي مكونات إضافية تلاحظ أنها مفقودة.
أفضل الممارسات؟ احتفظ بقائمة مرجعية في مكان ما، يمكنك إضافة واحدة في واجهة المستخدم
admin update بإضافة هذا الـ CSS إلى السمة الخاصة بك (../admin/customize/themes/ edit css) إذا كان لديك أو لدى شخص ما فكرة التحديث بسرعة كبيرة في يوم من الأيام:
.admin-contents.update .d-nav-submenu::before {content:“قائمة التحقق من التحديث” : تم عمل نسخة احتياطية؟” ; “قراءة آخر إعلان شهري لـ Meta؟ التحقق من أهم أخطاء Meta للشهر الماضي؟ التحقق من توافق المكونات الإضافية الأساسية؟ التحقق من توافق إصدار Postgres/Redis؟ التحقق من التوقيت المناسب للتحديث؟ التحقق من توفر القوى العاملة لاستكشاف الأخطاء وإصلاحها في حالة فشل التحديث؟ }
تعد قوائم المراجعة فكرة جيدة. بالنسبة لي، أفكر في الترقية، أنتظر الإصدار، أنتظر يومين، أنتظر يوم عمل، أقرأ فئات الأخطاء والدعم لمعرفة المشاكل التي يواجهها الأشخاص. وأنتظر إصلاح هذه المشاكل، إن وجدت.
أنت على الإصدار المستقر على الأرجح؟ وإلا فإن هذه الاستراتيجية لن تساعد في التكامل المستمر…
لا، أنا على tests-passed. صحيح أن تأخيري لبضعة أيام سيسمح بإضافة بعض الالتزامات المتفرقة الأخرى إلى المستودع، ولكنه في الوقت نفسه يسمح بتصحيح بعض الأخطاء. جميع الالتزامات تقريبًا، بالطبع، ليست إشكالية، لذلك أعتقد أنها مقايضة جيدة، ولكن قد تختلف الآراء.
هناك طفرة في الترقيات بعد فترة تجريبية جديدة مباشرة، لذا حتى في الاختبارات التي تم اجتيازها، يعد مرور بضعة أيام بعد الترقية وقتًا جيدًا للترقية. أو ربما نتشارك نفس المنطق المعيب!
ما زلت غير مقتنع بدون رسم بياني داعم. 
أعتقد أنك سترى شيئًا مثل نسبة الالتزامات المتعلقة بالأخطاء (لست متأكدًا من كيفية تحديد ذلك - ربما مجرد عد تلك التي تحتوي على “FIX” في الالتزام؟) للأيام الخمسة التي تلي الإصدار مقارنة بالنسبة لبقية الوقت.