لقد كنا نناقش بعض الأفكار داخليًا حول كيفية تحسين صفحة “تحديث Discourse”.
إحدى الأفكار هي إظهار سجل التحديثات، مع روابط إلى سجلات التغييرات للفروقات بينها (مما قد يكون مفيدًا لفهم التغييرات التي تلاحظها بعد إجراء تحديث).
إليك بعض الأفكار/الشكاوى الأخرى التي طرأت للتو:
ما هي الأفكار الأخرى التي يراها الجميع؟
مرحباً،
إليك الفكرة التي أعود إليها مراراً وتكراراً: معظم الإحباط الناتج عن عبارة “يتوفر إصدار جديد مع كل عملية تثبيت (commit)” ينبع من حقيقة أن قناة latest تتحدث بشكل مستمر، لذا فإن التخلف بضع عمليات تثبيت عن الإصدار الحالي هو في الواقع الحالة العادية للراحة، لكن الصفحة تعامل الأمر وكأن هناك مشكلة ما. لذا، بدلاً من إعادة تصميم النظام بالكامل، سأركز على تمييز الإشارة المفيدة عن الضوضاء.
الطريقة التي أتخيلها بها هي أن تحتوي الصفحة على شريط حالة واحد يتغير معناه اعتماداً على موقعك الفعلي:
latest → رمادي/معلوماتي، ويذكر صراحةً لا حاجة لاتخاذ أي إجراء. هذه هي الحالة التي “تصرخ” حالياً ولا ينبغي أن تفعل ذلك.v2026.8.0) → بارز، مع رابط إلى ملاحظات الإصدار.فقط الحالتان الأخيرتان يجب أن تشعر المستخدم بالحاجة إلى اتخاذ إجراء.
بعض الأمور الأخرى التي أود تضمينها هناك:
v2026.8.0-latest.1 · dfe770d · latest). هذه هي الشكوى الأكثر شيوعاً التي رأيتها، ومن السهل استعادتها.بشأن المكونات وإعادة البناء: الشيء الذي أود أن أراه مُوضَّحاً بوضوح هو التمييز بين التحديثات التي يمكن لمُحدّث الويب تطبيقها بنفسه (النواة + الإضافات، عبر git pull) وتلك التي تغير الحاوية (container) وبالتالي تتطلب تشغيل ./launcher rebuild app من سطر الأوامر. قائمة لكل مكون حيث تعرض كل صف المجموعة التي ينتمي إليها ستساعد كثيراً، وفي حالة إعادة البناء يمكنها عرض الأمر الدقيق مع زر للنسخ بدلاً من تركك تخمن.
بشأن توافق الإضافات: آلية .discourse-compatibility تتعامل بالفعل مع الحالة التي تكون فيها نواتك أقدم مما تستهدفه الإضافة حالياً؛ فهي تتحقق بهدوء من آخر عملية تثبيت متوافقة لتلك الإضافة أثناء إعادة البناء. هذا يؤثر في الغالب على التثبيتات المستقرة/ESR، ويحدث اليوم بصمت. سيكون من الجيد عرضه كسطر معلوماتي بسيط “مُثبت عند إصدار متوافق” حتى يتمكن المسؤولون على الإصدارات الأقدم من رؤية سبب عدم وجود الإضافة على أحدث عملية تثبيت لها. (الحالة المعاكسة، وهي عدم دعم الإضافة لنواة أحدث، غير معالجة حالياً؛ هناك طلب ميزة مفتوح يتعلق بالإصدارات الدنيا/العظمى المتوافقة الذي سيتعامل مع ذلك.)
لقد جمعت بسرعة نموذجاً تفاعلياً سريعاً لأرى كيف تبدو الحالات المختلفة جنباً إلى جنب؛ بصراحة، أكبر مكسب هو مجرد حالة “أنت متأخر لكن لا بأس بذلك”.
بمجرد أن تتوقف هذه الحالة عن كونها إنذاراً، تصبح الصفحة مفيدة حقاً مرة أخرى. يسعدني مشاركة النموذج إذا أراد أي شخص تجربته.
محتوى جيد.
توضيح واحد فقط حول هذا الجزء:
أعتقد أن الأمر يتعلق بالتحديثات التي قمت بها أنت، وليس بالضرورة “الإصدارات” التي نقوم بها نحن.
لذا، في كل مرة تقوم فيها بتحديث، سيظهر صف جديد. قد يكون هذا الصف لـ 5 التزامات (commits) ضمن إصدار واحد. أو قد يكون من الإصدار 2026.1.6 إلى 2026.7.1 إذا انتظرت أول إصدار تصحيحي بعد إصدار ESR التالي قبل التحديث.
على أي حال، من المفترض أن يعرض لك تاريخ التحديثات التي قمت بها أنت لموقعك سابقاً، ومجموعة التغييرات بين هذه التحديثات.
أضف ملاحظة بارزة حول أهمية عمل نسخة احتياطية أولاً!
أضف ملاحظة حول أنه، في حال فشل التحديث، فإن الخطوة التالية هي إعادة بناء المشغل عبر سطر الأوامر (CLI). على الأقل، أضف تنبيهاً يفيد بأن التحديثات قد تفشل أحياناً، مما سيؤدي إلى إيقاف المنتدى عن العمل.
والمثالي هو وجود طريقة للإشارة إلى أن التغييرات المعلقة تتضمن أمراً جوهرياً، مثل ترقية إصدار قاعدة البيانات التي حدثت مؤخراً، والتي كانت، في المرة السابقة التي حدثت فيها، حدثاً كبيراً حقاً، من حيث عدد المواضيع التي تم إنشاؤها هنا لطلب الدعم. على حد علمي.
أه، هذه صياغة أفضل من صياغتي، فأنت على حق. كنت أتخيل قائمة بإصداراتك، لكن سجل التحديثات التي نفذها هذا الموقع فعلياً هو أكثر فائدة.
إذن، يمثل كل سطر حدث تحديث ويوضح الانتقال من ← إلى، والمجموعة التغييرية التي كانت بينهما. وهذا يغطي بالطبع الحالتين: زيادة إصدار صغيرة ضمن قناة مع بضعة التزامات، أو قفزة كبيرة مثل v2026.1.6 → v2026.7.1، عندما ينتظر شخص ما التصحيح الأول بعد إصدار النسخة التالية من ESR.
