أؤيد ما قاله الآخرون، أنا أحب اتجاه التغييرات المقترحة. وأعتقد أن أسماء الفروع المقترحة أكثر بديهية من الأسماء القديمة 
ما ليس واضحًا تمامًا بالنسبة لي بعد هو كيف ستعمل عملية الترقية لفروع release و esr (يبدو أن latest مباشر). تذكر أنه في كل نقطة زمنية، سيتم دعم كل من الإصدار الحالي (لنسميه n) والإصدار السابق (n-1)، وأنه بصفتي مسؤولاً، سيكون لدي خيار بشأن وقت الترقية.
الآن بناءً على تجربتي مع البرامج الأخرى، عندما يصل إصدار جديد (n+1)، سأُخطَر بتوفر الإصدار n+1. ويمكنني بعد ذلك أن أقرر إجراء ترقية رئيسية (مكافئة لـ apt dist-upgrade على سبيل المثال في لينكس) أو إجراء تحديث بسيط/قياسي (مكافئ لـ apt upgrade على سبيل المثال في لينكس) والبقاء على الإصدار n. هل هذا شيء سيتم تضمينه في البرنامج النصي لمشغل Discourse؟
أيضًا، أتفهم الرغبة في تقليل مراسم/عملية الإصدار إلى الحد الأدنى، ولكن حدسي سيشير إلى أن إصدارات الإصدار العادية و ESR تتلقى على الأقل القليل من الاختبار الإضافي، قبل إصدارها. قد يكون ذلك ناتجًا عن العمل لفترة طويلة جدًا في تكنولوجيا المعلومات المؤسسية، على الرغم من ذلك 
أخيرًا، أتساءل عما إذا كانت الإصدارات الشهرية “سريعة جدًا” بالفعل. هذا بالطبع ذاتي أيضًا، ولكن بالنظر إلى تجربتي الخاصة في إدارة أشياء تكنولوجيا المعلومات بشكل جانبي كمتطوع، قد لا يكون لدي وقت للتحديثات الكبيرة كل شهر. وبناءً على ذلك، كنت أتساءل عما إذا كان بإمكانك أيضًا جعل حياتك كمطورين لـ Discourse أسهل قليلاً عن طريق إصدار ربع سنوي ببساطة، وعدم وجود فروع esr منفصلة، ولكن فروع release فقط.