When I get that “New Discourse version, update available” email from my forum (this time about 2.1.0.beta1), I know @jomaxro 's elaborate release notes will appear here within 6-24 hrs. or so. It’s not very important, but I would organize it in a different order.
إعجاب واحد (1)
I agree, first thing I do is go and look at the release notes to determine whether or not I am going to apply the update.
إعجابَين (2)
There is a high level release note list here: Discourse Version 2.1
إعجاب واحد (1)
The notes are in the above topic, so this is covered.
I’m not seeing any notes specifically for 2.1b1. Just a general list of goals for the final version of 2.1.
I’m off today (family event), will respond to this properly next week. Short version: there are no major changes from the last release notes (2.0.0.beta10) and 2.1.0.beta1 - we simply pushed 2.0 to stable and moved work to 2.1.
4 إعجابات
تم تحديث هذا المنشور آخر مرة 2021-06-28T04:00:00Z لتفصيل العمليات الحالية.
مرحبًا بالجميع! لدينا عدة مواضيع للمناقشة هنا، دعوني أرى إن كان بإمكاني تغطيتها جميعًا.
كان هذا قرارًا متعمدًا من جانبنا. لا نملك نظامًا رسميًا للإصدارات في نسخ الاختبار (Beta). نطلق إصدارًا جديدًا عندما يكون ذلك منطقيًا بالنسبة لنا. وعليه، عادةً ما يكون هناك تحذير قصير قبل الإصدار، وبالتالي لا يتوفر الكثير من الوقت لكتابة ملاحظات الإصدار. قرر @codinghorror أن انتظار جاهزية الملاحظات قبل الإصدار لا يبرر تأخير الإصدار نفسه.
يتم الآن تنسيق إصدارات الاختبار (Beta) بين فرق الهندسة والمجتمع. يجب أن تكون ملاحظات الإصدار نشطة في نفس وقت إصدارات الاختبار، إن لم يكن قبلها بوقت قصير.
لن ترى ملاحظات إصدار لـ beta1. لتجنب الالتباس، تُكتب ملاحظات الإصدار لجميع إصدارات الاختبار. الإصدارات المستقرة ستحصل أيضًا على ملاحظات. تجدر الإشارة إلى أن beta1 (من أي إصدار) متطابقة تقريبًا مع آخر إصدار اختبار من الإصدار السابق.
لفهم سبب ذلك، سأحتاج إلى شرح بعض التفاصيل حول كيفية تكوين فروعنا.
لأغراضنا هنا، نحتاج إلى معرفة 4 فروع من Discourse: main، tests-passed، beta، وstable.
Main:
عند إضافة commit جديد إلى Discourse، يكون في الفرع الرئيسي (main). الفرع الرئيسي هو أحدث فرع (الأكثر حداثة) في Discourse، ولا ننصح أي شخص بتشغيل موقعه متبعًا فرع main.
Tests-passed:
عند دفع commit جديد إلى الفرع الرئيسي، يقوم خادم البناء تلقائيًا بتشغيل جميع اختباراتنا على أحدث الكود. بمجرد نجاح جميع الاختبارات، يُضاف commit إلى فرع tests-passed. هذا هو الفرع الذي تعمل عليه جميع مواقع Discourse افتراضيًا.
Beta:
كل بضعة أسابيع، ندفع التأكيدات الحالية في tests-passed إلى beta. نستخدم النسخة التجريبية (beta) كـ “مرحلة” لإطلاق مجموعة من التأكيدات نريد أن يعمل عليها مواقع أكثر لاختبارها. كما ندفع نسخة تجريبية إذا كان لدينا إصلاح أمني مهم نريد أن تستقبله المواقع. عند دفع نسخة تجريبية، تتلقى جميع المواقع التي تعمل على tests-passed أو beta بريدًا إلكترونيًا بعنوان “تحديث جديد متاح”. المواقع التي تعمل على tests-passed ستقوم بالتحديث إلى التأكيدات الحالية في tests-passed (بما في ذلك أي تأكيدات جديدة تم دفعها بعد النسخة التجريبية)، بينما المواقع التي تعمل على beta لن تفعل ذلك.
Stable:
كل 4-6 أشهر، نطلق بناءً جديدًا stable. قبل حوالي أسبوعين من دفع النسخة المستقرة، نطلق آخر نسخة تجريبية. ثم نراقب سجلاتنا عن كثب لمحاولة التقاط أي أخطاء متبقية موجودة، ونتجنب إضافة أي ميزات جديدة أو تغييرات محفوفة بالمخاطر. بمجرد أن نشعر بالرضا عن حالة النسخة التجريبية الحالية، نضغها إلى النسخة المستقرة.
بناءً على ما سبق، دعونا نستخدم 2.0.0 كمثال. قمنا بدفع 2.0.0.beta10 في 16 مايو. تلقى جميع المستخدمين الذين يعملون على tests-passed أو beta بريدًا إلكترونيًا (ونفترض أنهم قاموا بالتحديث). كتبت ملاحظات الإصدار لتلك النسخة التجريبية. بعد حوالي أسبوعين، في 31 مايو، قمنا بدفع هذا البناء إلى النسخة المستقرة كإصدار 2.1.0. لضمان حصول المستخدمين الذين يعملون على tests-passed أو beta على التحديث أيضًا، قمنا بدفع نفس البناء كـ 2.1.0.beta1.
هل كل هذا واضح؟ هل هناك شيء يمكنني فعله بشكل مختلف في release-notes في #feature:announcements لجعل الأمر أكثر وضوحًا؟
20 إعجابًا