هل النسق "بيتا" دائمًا؟

لاحظت من حين لآخر أن موقع Discourse يرسل لي بريدًا إلكترونيًا يبلغني بوجود إصدار جديد جاهز للتثبيت، لكن في كل مرة يكون الإصدار بصيغة “x.y.z.beta شيء ما”. لذا أود أن أعرف: هل يكون Discourse دائمًا في مرحلة “beta”؟ هل من الجيد تثبيته في بيئة إنتاجية (أي لخدمة مئات، وربما آلاف الأشخاص)؟ أم أن هذا الأمر يخص النسخ المجانية فقط وليس نسخ “السحابة”؟

6 إعجابات

هناك شرح جيد للفروع التي نستخدمها هنا:

لذا، فإن Discourse في حالة تجريبية مستمرة، مما يعني أننا نعمل دائمًا على ميزات جديدة وتحسينات. في حالتنا، لا تعني النسخة التجريبية عدم الاستقرار؛ فنحن نستضيف مواقع بها ملايين مشاهدات الصفحة شهريًا على نسخنا التجريبية ونسخ tests-passed.

24 إعجابًا

لإضافة ما نشره @awesomerobot:

تختلف تسميتنا قليلاً عن شركات البرمجيات الأخرى، لكن ما نعنيه عندما نطلق إصدارًا تجريبيًا (beta) هو أننا نطلق إصدارًا تدريجيًا جديدًا. لقد قلنا: “هذا كافٍ من التغييرات في الوقت الراهن. دعنا نبلغ المواقع عن التحديثات الجديدة.”

لذا، بالنسبة لنا، الإصدار التجريبي (beta) هو ترقية طفيفة للإصدار، بينما الإصدار (version) هو ترقية كبرى للإصدار. إنها نقاط مرجعية نضعها لأنفسنا للاحتفال بالعمل الذي أنجزناه. نميل إلى إطلاق إصدارين كبريين سنويًا، لكن ذلك يعتمد على تطوير الميزات وما إلى ذلك. نحن لسنا مهتمين بالمواعيد النهائية الوهمية.

فيما يتعلق بالفروع

الإصدارات المستقرة/التجريبية ليست بالضرورة أكثر “استقرارًا” من الإصدارات التي اجتازت الاختبارات. الفكرة الأهم هي أن الأخطاء معروفة. أما في حالة اجتياز الاختبارات، فقد تُكتشف أخطاء جديدة ثم تُصلح بعد بضع عمليات إحداث (commits).

لا يختلف اجتياز الاختبارات كثيرًا عن معظم إصدارات البرمجيات الأخرى التي عادةً ما تطلق تغييرات صغيرة كل أسبوعين. نحن نلتزم بتغييرات جديدة تقريبًا يوميًا، وهي متاحة عبر إصدارات اجتياز الاختبارات.

17 إعجابًا

أنا في هذا الموضوع لنفس السبب.
لماذا لا تخبرنا تعليمات التثبيت بتثبيت الفرع المستقر؟

كيف يمكنني التبديل إلى الفرع المستقر أو هل فات الأوان بما أنني على “إصدار أعلى”
هل يمكن تحديث التعليمات؟

إذا فات الأوان، كيف أبقى على الفرع المستقر بمجرد تحديثه؟
هل أحتاج إلى الاستمرار في التحديث التدريجي حتى أصل إلى هناك؟

إعجابَين (2)

لا يمكنك التبديل إلى الإصدار المستقر حتى يلحق به. لا يدعم Discourse التراجعات.

السؤال الأفضل هو: لماذا قد ترغب في ذلك؟

الإصدار المستقر لا يُستخدم على نطاق واسع، والتركيز في التطوير يكون على الاختبارات التي تم اجتيازها.

بافتراض أنك لا تقوم بترقية موقع إنتاجي بشكل أعمى، وتقوم باختبار كل ترقية قبل النشر، فإن الإصدار الأكثر ثراءً بالميزات والأكثر دعمًا سيكون هو الافتراضي.

4 إعجابات

عذرًا، يجب أن يكون هذا نوعًا من مشكلة حاجز اللغة، ولكن هل يعني التركيز

  • تطوير Discourse نفسه وكيفية بناء الفروع
  • أن الجميع الآخرين يقومون بمعظم تطوير Discourse

الأول يعني أن مواقع الإنتاج التي تركز على المنتديات الوظيفية والمستقرة يجب أن تستخدم اجتياز الاختبارات.

الثاني يعني أن موقع إنتاج، يقوم بإنتاج المنتدى، وليس البرمجة، يجب أن يستخدم المستقر.

نعم. أنا بحاجة ماسة إلى بعض دروس اللغة الإنجليزية لأن هذه الفروق الدقيقة ليست واضحة تمامًا بالنسبة لي.

ولكن إذا كان التخمين الأول صحيحًا، فلماذا يوجد فرع مستقر إذا لم يكن المقصود استخدامه؟

إعجابَين (2)

نحن نشغل tests-passed في بيئة الإنتاج على الاستضافة الخاصة بنا. إنه مخصص 100٪ لمواقع الإنتاج.

stable يعني أن جميع أخطاء البرامج معروفة. لن تحصل على أي شيء جديد (بما في ذلك الأخطاء الجديدة، ولكن أيضًا إصلاحات الأخطاء) حتى يتم إصدار الإصدار المستقر التالي. إنها ببساطة تفضيل للموقع - هل تريد الميزات فور وصولها؟ استخدم tests-passed. هل تريد إصدارًا مستقرًا تمامًا لن يتغير إلا في تحديثات الإصدار الرئيسية؟ استخدم stable.

10 إعجابات

أضيف إلى ذلك “هل تريد الانتظار من 6 إلى 8 أشهر لإصلاح شيء ما يعتبر خطأ ولكنه لا يُعتبر خطرًا أمنيًا؟” استخدم stable.

11 إعجابًا

هذا ليس صحيحًا تمامًا. هناك العديد من إصلاحات الأخطاء التي تم نقلها إلى الإصدارات المستقرة.

4 إعجابات

حسنًا، هذا صحيح تمامًا أنا متأكد.
لكن المبالغة هي أفضل شيء على الإطلاق!

5 إعجابات

صحيح، تلك التي توقف العرض. الأخطاء الأصغر ليست كذلك.

إعجابَين (2)

سيكون من الجيد لو كان هناك خيار في التعليمات العامة، يشبه خيارات تنزيل LibreOffice أو Debian.

أنا أستضيف الموقع على DO ولكن مالك مشارك لي كان في الأصل من discoursehosting.net كاسم نطاق فرعي، ويرى كل هذه الصيانة ويقول “لماذا لا نستخدم استضافة discourse فحسب؟”

أخبرته أن لدينا اسمنا الخاص، وخادمًا، وإضافات ذات مستوى أعلى (مثل الإعجابات بالرموز التعبيرية وتسجيل الدخول عبر Google)، وأشياء أخرى. أخبرته أنه ربما كان يستخدم discourse قديمًا ولم يقم بالتحديث أبدًا.

أنا أيضًا أفضل استخدام الإصدار المستقر ونسيانه حتى بعد 6 أشهر. أنا مستخدم يومي لنظام Ubuntu، لكنني أشعر بقليل من التوتر عند كتابة أوامر البناء القليلة تلك. بالإضافة إلى أن الخادم يتعطل لمدة 5 دقائق عندما أقوم بإعادة البناء.

من ناحية أخرى، سأطلب دمج ميزة النسخ الاحتياطي وسأشارك في النسخة التجريبية لها :rofl:

لتجنب أي نوع من التكهنات: في Communiteq (المعروفة سابقًا باسم discoursehosting.net) تحصل على اسم المضيف الخاص بك، والإضافات التي تختارها في خطة Professional وما فوق، ونحن نقوم بعمل نسخة احتياطية وتحديث المنتدى الخاص بك لك. لذا نعم، سيتم بالفعل حل معظم مشاكلك باستخدام الاستضافة المُدارة.

4 إعجابات

كانت المشكلة الأصلية هي طلب توفير خيار بناء مستقر في تعليمات تثبيت GitHub. أرى أنك توفر إصدارات مستقرة لعملائك. ربما يمكنك التكرم بشرح كيفية استنساخ وتثبيت إصدار مستقر؟ كان هذا أيضًا سؤالي الأصلي.

كمجموعة صغيرة وشبه خاصة، لا يوجد مبرر لأي شيء أقل من خادم DO بسعر 5 دولارات. ومع ذلك، لديك خدمة رائعة مقابل 40 دولارًا شهريًا للخطة الاحترافية أو الخطة الأساسية. أتمنى لك كل التوفيق. إنها صفقة جيدة مقارنة بخطط Discourse الرسمية. كل الخيارات رائعة لمن يستطيع تحمل تكلفتها. هذا هو الجزء الرائع في FOSS.

إعجاب واحد (1)

لقد اعتقدت أن قرار التثبيت على الاختبارات التي تم اجتيازها افتراضيًا متعمد تمامًا.

من الأسهل بكثير دعم عمليات التثبيت الجديدة على مستوى برنامج واحد. نظرًا لأن الدعم المقدم هنا يعتمد على المجتمع وهو مجاني بنسبة 100٪ في الغالب، فلا يوجد سبب وجيه لتعقيده.

5 إعجابات

تم تبسيط تعليمات التثبيت القياسية لسبب وجيه.
يعتبر تشغيل stable إعدادًا متقدمًا، لذا تحتاج إلى تعديل app.yml يدويًا. يمكنك البحث عن “version” ورؤية ما يجب فعله موثق هناك.

تعديل discourse-setup لتضمين هذا كخيار سيكون مربكًا لمعظم الناس، لذلك لا أعتقد أنه سيتم إضافته هناك.

إعجابَين (2)

ربما يكون الاستعارة المفيدة هي أن الفرع “المستقر” يشبه Microsoft Office المستند إلى القرص، بينما يشبه الفرع “tests-passed” Office 365 المستند إلى السحابة. كلاهما خياران قابلان للتطبيق، وكلاهما يحصل على تحديثات في النهاية، ولكن بالنسبة لمنتج متصل بالإنترنت بالفعل ولديه فريق دعم صغير، فمن الأفضل أن تكون قادرًا على توجيه الأشخاص لتحديث تثبيتاتهم إلى الرمز الحالي، بحيث يمكن اختبار الأخطاء وإصلاحها على الفور. بصفتي مسؤولًا في المنتدى، من الرائع أن أتمكن من الإبلاغ عن خطأ وتحديثه إلى إصدار يصلحه في غضون أيام قليلة، وأحيانًا في اليوم التالي. لم أستخدم أي تطبيقات ويب أخرى سريعة الاستجابة مثل ذلك. (ليس أن كل خطأ يتم إصلاحه على الفور، ولكن الكثير منها كذلك.)

11 إعجابًا

@pfaffman، لقد اتبعت الرابط والرابط الذي أدى إليه، لكنني لم أرَ شيئًا عن ضبط الإعداد على stable. ماذا أفوت؟ هل تقصد “البحث في ملف app.yml عن “version”؟”

لكنني لا أعتقد أنه يمكنك الانتقال من test-passed إلى stable (حيث ستعود في الالتزام وربما تحتاج إلى عكس بعض عمليات الترحيل في قاعدة البيانات، إلا إذا كان إصدار test-passed الخاص بك قديماً بما يكفي لتجاوزه بواسطة أحدث إصدار مستقر على ما أعتقد :thinking:)

4 إعجابات

شكرا على الرد السريع!

كنت أتوقع أن يتم تعليق التحديث حتى دورة الإصدار stable التالية.

أي رؤى حول هذا؟ لماذا قد يتغير أي شيء على الفور من تبديل مفتاح #version؟

إعجاب واحد (1)