لقد استغرق الأمر مني حتى الآن لأدرك أن هناك قناة مستقرة وأنني بحاجة إلى تعديل الإعدادات للترقية إليها.
أرى الآن خيار ترقية إلى 3.0.0.beta16 لمواقعي. إذا قمت بتعيينها إلى الإصدار المستقر الآن وقمت بالترقية، فهل ستنتقل إلى 3.0.0.beta16 ثم في النهاية إلى 3.0.0 مستقر؟
هل يمكنك شرح سبب اعتقادك بضرورة التبديل إلى المستقر؟
لست متأكدًا لماذا قد يحتاج المرء إلى سبب لتشغيل برنامج مستقر. أنا فقط أريد تحديثات أقل وبرنامجًا مستقرًا.
لا أعتقد ذلك. إذا قمت بالتبديل إلى stable، فلن تقوم إلا بتحديث الإصدارات الرئيسية، ولم يتم إصدار 3.0.0 بعد. كان آخر إصدار مستقر هو 2.8.0 (يمكنك رؤية آخر التحديثات في release-notes)
لا أعتقد أن ستيفن كان يحاول أن يكون مضحكًا. يتم استخدام Stable بمعنى كلمة مفتاحية لـ app.yml، وليس ككلمة إنجليزية. السبب في ذلك هو أن الكلمة المفتاحية الأخرى (الافتراضية)، tests-passed، يمكن وصفها بأنها مستقرة أيضًا: من غير المرجح أن تتعطل [1]، وفي الواقع، يمكن أن تكون أكثر “استقرارًا” (من الناحية الإنجليزية) إذا قمت بتحديث المكونات الإضافية و/أو مكونات السمات بشكل متكرر أكثر مما ترغب في تحديث Discourse.
في عامي في تشغيل Discourse، لم أواجه أبدًا موقفًا تعطل فيه شيء ما بسبب بعض الالتزام الجديد ↩︎
شكرا على المعلومات! أعرف أنه لم يكن يحاول أن يكون مضحكًا، لم يكن يبحث عن مناقشة الأسباب، فقط معلومات حول متى يجب الترقية للانتقال إلى المستقر. سأستمر في التحديث طالما أنه يقول ذلك وسأنتقل بمجرد أن أرى 3.0.0 يصل إلى المستقر.
كن على علم بأن إصدار الإصدار الرئيسي، على حد علمي، على فرع تم اجتياز الاختبارات فيه، يصاحبه إصدار n+1.beta1، لذا إذا كنت ترغب في تجنب كلمة “beta” في إصدارك، فيجب عليك التبديل إليه قبل التحديث إلى n+1.beta1.
في بعض الأحيان[1] تُصاغ الأسئلة بناءً على افتراضات خاطئة، ومن الأفضل فهمها مبكرًا.
يمكن القول غالبًا، إذا تعاملنا مع مواضيع “الرجاء المساعدة”. هذا في رأيي الشخصي مبني على مناقشات في منتداي أيضًا ↩︎
إذًا، على سبيل المثال، أنا الآن على الإصدار 2.9.0.beta14. هل يجب أن أغير الفرع في إعداداتي إلى stable ثم أنتظر فقط ظهور الإصدار 3.0.0 في قسم /admin الخاص بي، وسيظهر فقط التحديثات للإصدارات المستقرة من تلك النقطة فصاعدًا؟
عندما أقوم بتغيير ملف الإعدادات، هل يجب علي إعادة تشغيل حاوية docker؟
يمكنك الآن تغيير app.yml. ستحتاج إلى الانتظار حتى الإصدار لتشغيل أمر ترقية آخر عبر سطر الأوامر. ليس من الواضح عدد الإصدارات التجريبية الإضافية التي ستكون قبل إصدار إصدار مستقر جديد.
يعني الإصدار المستقر تحديثات أقل، ولكنه لا يعني بالضرورة أخطاء أقل. يتطلب تشغيله خبرة أكبر قليلاً من اجتياز الاختبارات. يتم تضمين تحديثات الأمان الهامة في الإصدار المستقر، ولكن من المحتمل أن تظل مشكلات تجربة المستخدم معطلة حتى الإصدار المستقر التالي. من غير المرجح أن تعمل الإضافات الخارجية مع الفرع المستقر نظرًا لأنه لم يتم اختباره بشكل جيد.
إذا كنت تريد تحديثات أقل، يمكنك ببساطة التحديث بشكل أقل تكرارًا.
شرح جيد لـ stable مقابل test-passed:
أعترف بأنني أشعر بالضغط والارتباك بسبب إشعار التحديث في صفحة المسؤول.
إنه مفاجئ جدًا في إخباري بضرورة التحديث فورًا، ولكنه يطلب مني التحديث إلى برنامج تجريبي. إنه متناقض إلى حد ما. أعتقد أنه يجب أن يُعلم المستخدم بوجود تحديث، ولكن يجب فقط دفع المستخدم للتحديث في أسرع وقت ممكن إذا كان هناك مشكلة أمنية أو خطأ حرج في الإصدار الحالي لديهم.
ربما يمكن إزالة علامة “تجريبي” إذا كان يعتبر مستقرًا أو تغييره إلى tests-passed حتى يشعر المسؤولون براحة أكبر في التحديث، مع العلم أنهم يحصلون على برامج تم اختبارها بالكامل ومستقرة.
بدلاً من ذلك، يمكن إسقاط علامة “تجريبي” وتسميته مستقرًا كما هو مكتوب هنا، ثم يمكن تسمية الإصدار المستقر الحالي بـ LTS.
هذا بالضبط ما يحدث، عندما يخرج إصدار تجريبي جديد، تكون هناك (دائمًا تقريبًا) مشكلة أمنية خطيرة تؤدي إلى الإصدار الجديد.
وهو ما سيكون طريقة جيدة جدًا (أفضل، في رأيي) للنظر إلى الأمور بالفعل.