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