لا يصدر Discourse إصدار LTS

عام
1

لم أكن على علم بالتوافق مع الخطاب (discourse-compatability)، لذا سأحتاج إلى قراءة المزيد عنه.

أود معالجة هذا الأمر، لأنه يبدو أن هناك انفصالًا كبيرًا بين كيفية تفكير فريق Discourse في المستقر (stable) وكيف يفكر مجتمع الخطاب (Discourse) الأوسع / مجتمع مديري المنتديات الأكبر في العرض المستقر لـ Discourse.

الأسباب الرئيسية لعدم استيفاء المستقر (stable) لتعريف إصدار الدعم طويل الأمد (LTS).

1) يتم تثبيط استخدام المستقر (stable) بنشاط من قبل الموظفين كلما تم طرحه.

لا أرغب بالضرورة في استدعاء مشاركين فرديين، ولكن إليك مجموعة مختارة من منشورات الموظفين لإظهار الموضوع:

لاحظ أنه في بعض النواحي، يكون tests-passed أكثر استقرارًا من stable لأنه هو ما يعمل عليه discourse.org، لذا فهو الأكثر اختبارًا.

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

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

الرسالة كانت باستمرار أن Discourse في “تجريبية دائمة”، وهذا ليس ما يريده المستخدمون الإنتاجيون / غير المطورين.

في بحث سريع على DuckDuckGo عن أهم عشرة روابط للمستقر (stable) في Discourse، لا يبدو أن أيًا منها يدعم استخدام المستقر (stable) حقًا. لذا بغض النظر عن جودته الفعلية، إذا كان الموظفون يوجهون الناس عالميًا بعيدًا عن المستقر (stable)، فهذا يعطي انطباعًا سلبيًا في أذهان الناس بأنه غير مناسب للغرض.

قد يكون المستقر (stable) رائعًا، ولكن إذا قيل لنا مرارًا وتكرارًا أنه من الأفضل عدم استخدامه، فلن نأخذه في الاعتبار للنشر الجاد.

2. يتلقى إصدار الدعم طويل الأمد (LTS) إصلاحات للأخطاء تتجاوز مجرد إصلاحات الأخطاء الأمنية.

إصدار الدعم طويل الأمد (LTS) هو شيء لا يتلقى ترقيات للميزات، ولكنه يتلقى إصلاحات للأخطاء. وفقًا لتعليقات الموظفين الخاصة، لا يبدو أن هناك جهدًا يبذل في Discourse لإعادة تطبيق إصلاحات الأخطاء للمشكلات غير الأمنية. ربما هذا ليس صحيحًا، ولكن هذا ما قيل لنا.

3. إصدار الدعم طويل الأمد (LTS) لديه خطوات تثبيت واضحة.

دليل التثبيت (install guide) لا يذكر حتى وجود المستقر (stable).

4. إصدار الدعم طويل الأمد (LTS) مستخدم على نطاق واسع.

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

5. إصدار الدعم طويل الأمد (LTS) لديه دورة إصدار واضحة وملاحظات تحديث.

لا أرى أي مكان مركزي يتم فيه توثيق المستقر (stable) بوضوح. (قد أكون فقط أفتقدها!)

توقعاتي لإصدار الدعم طويل الأمد (LTS) هي صفحة تصف:

  • إصدار الإصدار النشط الحالي
  • ملاحظات الإصدار بما في ذلك:
    • التغييرات / الميزات الرئيسية بين إصدارات LTS
    • خطوات الترحيل من إصدار LTS السابق (خاصة التغييرات الكاسرة التي يجب الانتباه إليها)
    • طول الدعم النشط المخطط له لكل إصدار

مثال: mediawiki، ولكن في الواقع أي إصدار LTS رئيسي مفتوح المصدر لديه صفحات مماثلة.

تساعدني هذه الوثائق في التخطيط عندما يكون هناك تغيير كاسر يتطلب وقت تعطل و/أو تدخل يدوي.

6. إصدار الدعم طويل الأمد (LTS) لا يحتوي على تغييرات كاسرة رئيسية ضمن دورة إصدار واحدة.

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

7. يوفر إصدار الدعم طويل الأمد (LTS) تحذيرات إهمال واجهة برمجة التطبيقات (API deprecation warnings) لدورة إصدار LTS كاملة واحدة على الأقل.

يجب قياس هذه التحذيرات بوتيرة سنة +، بدلاً من شهر +.

8. إصدار الدعم طويل الأمد (LTS) مُجدول / لديه فترات دعم متداخلة.

سيكون لدى أي إصدار LTS كبير فترة دعم متداخلة بين إصداري LTS. يبدو أن المستقر (stable) يقوم فقط بتبديل ثنائي إلى الإصدار التالي. (قد يكون انطباعي خاطئًا أيضًا بسبب عدم وجود صفحة توثيق مركزية)

9. من السهل الترقية من غير LTS إلى LTS.

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

أنا من محبي Discourse، ولكن هذه نقطة ألم شائعة أواجهها أنا والعديد من الأشخاص الآخرين. ما هو المستقر (stable) الآن هو مجرد فرع، وليس إصدار دعم طويل الأمد (LTS).

4 إعجابات
2

تم نقل هذا إلى موضوع خاص به، ويبدو أنه غير مرتبط بتجميع المكونات الإضافية.

3 إعجابات
3

إذا أخذنا في الاعتبار الوجه الحزين في لوحة تحكم المسؤول مقابل وجود العديد من الـ commits المتأخرة في “تحديث discourse”
هل التحديث الحرج جزء من tests-passed وإذا قمت بـ “تحديث الكل” فورًا بعد الوجه السعيد إلى الوجه الحزين، فستكون متزامنًا مع tests-passed

4

أعتقد أن هذا التحديث المحدد يتطلب إعادة بناء من وحدة التحكم. مرتين.

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

يبدو أن Discourse تتمتع بسرعة عالية من حيث التغيير وخارطة طريق طموحة.

لدعم ذلك، تحتاج إلى الكثير من ملاحظات المستخدمين. أعتقد أن هناك استراتيجية ضمنية واضحة لتعزيز tests-passed لأن ذلك يدعم الملاحظات المبكرة على التغييرات الجديدة.

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

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

القضية الأخرى مع المستقر هي هذه، وهي أكثر أهمية:

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

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

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

الجانب الآخر المهم في Discourse هو تركيزه الشديد على اختبارات الوحدة، لذا فإن فرع test-passed جيد جدًا عادةً من منظور الاستقرار.

4 إعجابات
6

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

أعتقد أن السبب الأكثر واقعية لعدم دعمهم لـ LTS مناسب هو أنه سيكلف شخصًا ما في الفريق وقتًا لإدارته/توثيقه. إنها ميزة تفيد بشكل أساسي من يستضيفون بأنفسهم، لذا أتخيل أنها ستعتبر مضيعة للوقت بالنسبة لهم. لكنها نوع من الميزات المتوقعة وعدم وجودها يمثل عيبًا حقيقيًا عندما يختار مسؤولو المنتديات برامج المنتديات الخاصة بهم نظرًا لأن المعاصرين الآخرين لديهم عروض أكثر استقرارًا.

7

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

8

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