لا يوجد تعريف رسمي لـ “verified” على حد علمي.
كل البرامج قد تكون بها أخطاء.
tests-passed يحتوي على أحدث الالتزامات. beta يحصل على إصدارات البيتا فقط. stable يحصل على الإصدارات المستقرة فقط.
tests-passed هو ما يعمل على جميع المواقع المستضافة على discourse.org تقريبًا والغالبية العظمى من المواقع المستضافة ذاتيًا.
@mcwumbly – هل لدينا وثيقة “ما هي النسخة التي يجب أن أشغلها”؟ بحثت قليلاً ولم أجد شيئًا. كل ما أتذكره هو شيء مثل هذا من إعلانات stable.
هناك
ربما تكون هذه بداية جيدة لموضوع
يتم اقتباس هذا المنشور هنا أيضًا: Is Discourse always in "beta"?
ولدينا هذا الموضوع: Configure a supported tracking branch to get Discourse software updates
أتفق على أن هذا شيء يجب أن يكون لدينا موضوع أفضل حوله حيث يمكننا الإشارة بوضوح أكبر إلى توصيتنا بأن نكون على tests-passed.
بشكل منفصل، أنا مغرور إلى حد ما بالتخلص من beta (قد أبدأ موضوعًا جديدًا حول ذلك).
يجب علينا أيضًا شرح الفرق بين الإصدارات (builds) وكيفية تغيير الإصدار الذي تستخدمه في تعليمات التثبيت https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md. لقد قمت بفحصه للتو ولم أجد أي ذكر له.
لقد قمت بفصل هذا (أعتقد أنها المرة الأولى التي أفعل فيها ذلك!)، حيث لا يزال المسكين غير قادر على معرفة ما إذا كان “من الخطر” الترقية، وهذا النقاش حول كيفية حل مشكلة عدم معرفة الأشخاص بما إذا كانوا سيقومون بالترقية لا يساعد.
في الواقع، Updates always come before release notes - #7 by jomaxro هو بداية جيدة، أو ربما كل ما هو مطلوب. فقط أعطه عنوانًا مناسبًا خاصًا به.
ربما https://meta.discourse.org/t/is-discourse-always-in-beta/198215، هو ما كنت أبحث عنه (لكنني نسيت أنه كان موجودًا لأبحث عنه).
الشيء الآخر الذي سأله، وهو المكان الذي بدأ فيه، وأعتقد أنه معقول جدًا، هو “إذا كنت على أحدث إصدار تجريبي، فلماذا أحتاج إلى الترقية؟” وهذا يعالج ذلك بشكل مباشر إلى حد ما.
الإجابة معقدة بشكل مدهش.
ممتاز. انتهت مهمتي هنا. 
لا أعتقد أنه يجب علينا ذلك. نريد أن يكون الأشخاص على tests-passed. يجب أن تؤدي تعليمات التثبيت الرسمية إلى تثبيت افتراضي مع أكبر عدد ممكن من الإعدادات التي تتطابق مع ما نريده. وهذا يشمل الفرع الذي يتم تتبعه.
سيظل هناك دائمًا أشخاص يرغبون في استخدام أحدث إصدار مستقر على سبيل المثال. عدم وجود دليل حول كيفية تحقيق ذلك في أكثر الأماكن سهولة لا يجعل هؤلاء الأشخاص يختفون؛ بل يجعل الأمور أقل ملاءمة لهم - وغالبًا ما يعني ذلك أنهم يأتون إلى هنا للسؤال، ويقضي الآخرون وقتًا في الإجابة على السؤال (مرارًا وتكرارًا).
الحجة الأقوى على الأرجح هي أن الدليل يمكن أن يوضح لهم كيفية القيام بذلك بشكل صحيح، مما يعني أنهم قادرون على التراجع لاحقًا إذا غيروا رأيهم. إذا لم يعرفوا، فقد ينتهي بهم الأمر إلى كسر تثبيتهم، مما سيكون غير مريح لهم ولمجتمعهم.
إذا كان ملف INSTALL-cloud.md يحتوي على قسم حول تغيير الفرع، فيمكنه توضيح ما هو الافتراضي ولماذا، مما يوضح أن الافتراضي هو الأكثر استخدامًا، والأسهل في الدعم.
أنا سعيد بنسبة 100٪ لوجود دليل على Meta حول كيفية تغيير الفروع. أنا فقط لا أعتقد أنه ينتمي إلى دليل التثبيت الرسمي، حيث لا يهتم 95٪ من الأشخاص أو يحتاجون إلى الاهتمام.\n\nإذا كان Basic Bob يحاول تثبيت Discourse، فهو يريد فقط المرور بالتثبيت بأسرع وسهولة ممكنة، حتى يتمكن من العمل على موقعه الجديد. المعلومات حول تغيير الفروع ستجعله يفكر أكثر، وتسبب الارتباك.\n\nمن ناحية أخرى، قد يكون Advanced Ally مهتمًا بفهم كيفية عمل الفروع وأيها هو الأفضل لموقعه. لكنها من المحتمل أيضًا أن تقوم بمزيد من البحث قبل تثبيت Discourse، وليس مجرد المرور بدليل التثبيت.
بالفعل، كما هو الحال، نحصل على مواضيع عرضية من المستخدمين الذين يرغبون في العودة إلى الإصدار التجريبي أو المستقر وفشله.
إن وضع ذلك في وثائق التثبيت القياسية سيفتح الأبواب حقًا، سواء بسبب المشكلات المذكورة أعلاه أو مشكلات التوافق مع المكونات الإضافية مع الإصدارات الأقدم.
أتفق. في المجمل، أشعر أن beta تربك الناس أكثر مما تحقق فائدة.
أعتقد أنه من المفيد رسم تمييز هناك بين الأشياء التي تستخدمها ولها معنى داخلي والأشياء التي تعني شيئًا لأطراف ثالثة. فرع beta مثال جيد على ذلك. في حين أنه قد يكون له بعض الفائدة الداخلية، إلا أن له فائدة قليلة للأطراف الثالثة وغالبًا ما تربكهم.
سأكون مهتمًا بسماع ما يخالف ذلك، ولكن عند التفكير في الأمر الآن، لا أستطيع تذكر أي مستضيف ذاتي جاد يستخدم beta بأي شكل ذي معنى. “بوب الأساسي” لا يعرف حقًا ما هو الفرع ولا يهتم به (وهذا عادل). “آلي المتقدم” ستستخدم tests-passed إذا كانت فردًا أو شركة صغيرة ومتوسطة، وقد تستخدم stable (أو تثبيت الالتزامات) إذا كانت شركة متوسطة أو كبيرة الحجم.
اقتراحي هو الحفاظ على كل شيء متعلق بالفروع تمامًا كما هو ولكن نقول علنًا “لدينا فرعان يمكنك استخدامهما: tests-passed (الافتراضي والأفضل) و stable (إذا كنت تعرف ما تفعله ولديك حاجة معينة).”
من جهتي، مجرد رؤية اسم الفرع tests-passed بجوار اسم الإصدار على لوحة المعلومات سيكون تحسينًا كافيًا.
أتفق تمامًا. أي شخص يريد اختيار فرع مختلف، سيجده دائمًا تقريبًا.
إذا لم يتمكنوا من العثور عليه بالموارد الحالية (البحث، مشروع GitHub القياسي)، فهل هم حقًا مجهزون بالمهارات اللازمة لفهم الفرق بين الفروع بالكامل، ناهيك عن الابتعاد عن أمان الفرع الافتراضي؟
بالتأكيد، هذا منطقي. لكنني أشعر أننا نضيع فرصة لمساعدة الأشخاص على فهم الفرق بين الخيارات المختلفة هنا. لا أرى ضررًا في إخبار المستضيفين الذاتيين بأن الإعداد الافتراضي هو tests-passed وهو مثالي لمعظم المواقع، ويضمن حصولك على أحدث إصلاحات الأمان والتحديثات. إذا كنت تتجنب المخاطر، يمكنك تركها على tests-passed وتحديثها فقط عند مطالبتك بذلك في البرنامج، أو بعد أسبوع تقريبًا من تلقي المطالبة. بهذه الطريقة يكتشف الآخرون أي مشاكل أولاً ويتم إصلاحها قبل أن تقوم بالتحديث.
بالنظر إلى ما سبق، هل هناك أسباب مشروعة للمستضيفين الذاتيين للتبديل من tests-passed؟ أعتقد أنه إذا كان موقعك معدلًا بشكل كبير وسيتعطل إذا تم تحديث مكونات discourse الأساسية أو الإضافات الرسمية، ولا تثق بنفسك أو بمسؤولي النظام لديك في عدم التحديث؟ أو إذا كنت تقوم بإعداد بيئة تطوير أو بيئة اختبار؟
مكان آخر لشرح هذا يمكن أن يكون في app.yml، وهو حاليًا غامض إلى حد ما لأنه يشير فقط إلى tests-passed ولا يذكر الخيارات أو متى قد تنتقل إلى خيار آخر.
## ما هو مراجعة Git التي يجب أن يستخدمها هذا الحاوية؟ (الافتراضي: tests-passed)
#version: tests-passed
في رأيي، استخدام أي شيء آخر غير tests-passed له معنى فقط إذا كنت تستخدم خدمة استضافة مُدارة أو: 1) إذا كان لديك فريق يدير مجتمعك (أي أنك مؤسسة متوسطة إلى كبيرة الحجم)؛ و 2) لديك سبب محدد لعدم استخدام tests-passed، على سبيل المثال لديك العديد من التخصيصات التي قد تتعطل.
أود أن أقول إن كلا الشرطين ضروريان، لأنه ما لم يكن لديك فريق يدير مجتمعك في سيناريو التخصيصات المتعددة الهشة، فإن مشكلتك ليست استخدام الفرع الخاص بك ولكن إدارة موقعك بشكل عام (أي أنه غير مستدام).
حتى لو كان كلاهما صحيحًا، ستكون هناك أشياء أخرى يجب مراعاتها أولاً مثل سياسة التحديث الخاصة بك.
أعتقد أن المشكلة هي أنه إذا قلت شيئًا مثل “يمكنك استخدام stable أو tests-passed”، فإن بعض الأشخاص سيضعون stable هناك لأنها تبدو “منطقية” بينما لا ينبغي لهم استخدامها على الأرجح.
لزيادة الحجة ضد فرع beta، في سياقات مكتوبة ومنطوقة مختلفة، فإن الارتباك الرئيسي الذي تحدثه هو:
عادة ما يربط الناس مصطلح “beta” بشيء أكثر حداثة من “standard”. ليس هذا هو الحال هنا.
تفكر بعض المؤسسات في استخدامه لأنه يبدو أقل حداثة من tests-passed وأكثر تحديثًا من stable، أي مرة أخرى، يبدو “منطقيًا”. ولكن في معظم الحالات، هذه ليست فكرة جيدة.
“beta” هو مصطلح يستخدم في كل من أرقام إصدارات Discourse وكاسم فرع Discourse. لقد وجدت أن هذا يربك بعض الناس.
“بيتا” ربما تنفر بعض الأشخاص شبه المتعلمين للحاسوب مثلي - المعنى المعتاد هو “لا يزال قيد الاختبار للجودة” بدلاً من “لا يزال يضيف ميزات”.
أعتقد أنني أفكر في أسماء الإصدارات في الغالب بدلاً من اسم الفرع. لقد افترضت أنني كنت على فرع “بيتا” بناءً على أسماء الإصدارات (لست كذلك) حتى التحقق الآن، لذلك لم يزعجني أي من ذلك…
نعم. أعتقد أن هذا مربك (أو يمكنني أن أرى كيف قد يكون مربكًا) أنك على tests-passed ويظهر الإصدار باسم “beta” ولكن يمكنك إجراء ترقية والحصول على رمز جديد هو نفس الإصدار التجريبي الذي أنت عليه بالفعل. وهناك أسابيع ومئات الالتزامات بين الإصدارات التجريبية.
لقد أجريت بعض التعديلات على هذا الدليل لدمج بعض المناقشات والمواد المشار إليها أعلاه: Configure a supported tracking branch to get Discourse software updates