هذا النقاش لا يبدو جيدًا. أرى قرارًا من فريق التطوير بتبني نظام إصدار جديد منطقي بالنسبة لهم، وآخرين يبدو أنهم فجأة يعتبرون أن إصدار Discourse كان يتبع الإصدار الدلالي… وهو لم يكن كذلك. لقد كان دائمًا إصدارًا متدفقًا، على الأقل منذ 1.0، أو؟
لكن الحجج من جميع جوانب النقاش تبدو معيبة:
- “معيار الصناعة”: يستخدم لينكس الأرقام الزوجية للإصدارات المستقرة والأرقام الفردية للتطوير.
- “الأرض تدور حول الشمس”: حسنًا، إذا أسلمت، ستواجه مشكلة لأنك ستتخلى عن الإصدارات ولن تتوافق مع دوران الشمس، بل مع دورات القمر. هنا، تفهم الآن أنه باختيار مخطط إصدار YYYY.Y.Z بدلاً من X.Y.Z، فرضت ثقافة مهيمنة.
- الإصدارات الثانوية لا تزال غير واضحة: تذكر “بافتراض وتيرة شهرية”، ولكن يمكن أن تكون أيضًا 3 أسابيع أو 7، اعتمادًا على الوظيفة، وفي هذه الحالة يكون عد Y من 0 منطقيًا، أو هل تهدف بالفعل إلى الإصدار شهريًا، وفي هذه الحالة يكون عد M من 1 أكثر منطقية؟
التغيير الرئيسي الذي أراه هو أنه من خلال اعتماد وتيرة شهرية، يحدد فريق Discourse التوقعات ويتحرك بعيدًا عن أهداف الإصدار، ويتبنى الإصدارات المنتظمة بدلاً من ذلك.
LTS لمدة 8 أشهر لا تبدو “طويلة” حقًا. NodeJS يتحرك بسرعة كبيرة، لكنهم يحتفظون بدعم LTS لأكثر من 30 شهرًا وعدد قليل من الإصدارات الحالية في وقت واحد، بينما تحتفظ Ubuntu بـ LTS لسنوات. على الرغم من أنني أفهم أن Discourse ليس لغة ولا نظام تشغيل، إلا أنه يبدو أنه يعلن أن الوظائف الجديدة ستصدر بوتيرة سريعة جدًا، مما يثير قضية أخرى في ذهني: نظرًا لأنه يتم تقديم إعدادات إدارية جديدة من وقت لآخر، فسنصل قريبًا إلى جحيم ووردبريس بخيارات لا نهائية وتعقيد لا يمكن فهمه لإدارة الموقع، المعروف باسم البرامج غير المرغوب فيها: يصبح من المهم حينئذ توضيح كيفية الانتقال من الإصدارات الحالية بأهداف إلى الإصدارات المنتظمة، وكيف تختار الأهداف التي يجب إسقاطها (أو تأجيلها) لإصدار ما، وما إلى ذلك (والتي قد تكون موثقة بالفعل، لكنني فاتني ذلك.)
هل تتكرم بمشاركة منطقك بين وتيرة التطوير / الإصدار، وما الذي تفكر فيه لتجنب غرق المسؤولين تحت الكثير من الإعدادات ومنحنى تعلم مرتفع؟
