الواقع هنا هو أن الفرع المستقر هو بالفعل إصدار دعم طويل الأمد (LTS)، وهو جيد جدًا أيضًا. يتلقى تحديثات أمنية ومن الواضح جدًا أي إصدارات الإضافات متوافقة معه (بفضل ملف .discourse-compatibility). أعترف تمامًا أن الأمر استغرق وقتًا طويلاً قبل أن يبدأ كل هذا في العمل، ولكن في العامين الماضيين تقريبًا، نجح الأمر - وهذا إنجاز رائع للفريق.
الآن للجزء الثاني من بيانك. صحيح أن الفرع “المستقر” غالبًا ما يُنظر إليه على أنه شيء لا يجب أن تريده. ولكن في استضافة Communiteq، كنا نمنح العملاء حرية الاختيار بين المستقر (“الاستقرار أولاً، تحديثات جديدة مرتين في السنة، تحديثات أمنية مرة واحدة شهريًا”) والاختبارات المعتمدة (“دائمًا على الحافة، ميزات جديدة مرة واحدة شهريًا”) على مدار العامين ونصف الماضيين و 85٪ يختارون أن يكونوا على الفرع المستقر.
أتفهم ذلك. ولكن أليس هذا مشكلة تطوير وليست مشكلة إنتاج؟ يمكنني أن أفهم تمامًا أنك تفعل هذا في بيئة التطوير. ولكن إضافة هذه الإضافات في تثبيت إنتاج افتراضي يقوض فكرة وجود إضافة (وهي شيء غير افتراضي بحكم تعريفها).
الفائدة الإنتاجية الفعلية الوحيدة التي أراها هي مشكلة هامشية جدًا جدًا تتعلق بـ إلغاء تثبيت الإضافات ومضيفي المواقع المتعددة. (مرة أخرى، هذا شيء جيد، تم حل جميع مشاكل الإنتاج الأخرى بمرور الوقت!)
كان يمكن حل ذلك أيضًا في برنامج الإعداد عن طريق عرض قائمة بالإضافات التي يمكن للمستخدمين تحديدها ثم إضافتها إلى app.yml.
ولكن ما زلت تقدم مجموعات مختلفة (فرعية) من الإضافات لمستويات مختلفة، أليس كذلك؟