مطورون ينتقدون مدة دعم LTS لمنصة .NET من Microsoft البالغة ثلاث سنوات

أعاد مطور فتح جدل قديم حول سياسة دعم منصة .NET من Microsoft، إذ أنشأ issue جديداً على GitHub يرى فيه أن نافذة الدعم طويل الأمد البالغة ثلاث سنوات قصيرة جداً لدورات تحديث الأنظمة المؤسسية.

كيف يعمل نموذج الدعم الحالي لـ .NET

يقسّم نظام Microsoft الحالي إصدارات .NET إلى نوعين من حيث مدة الدعم، وهذا النظام تحديداً هو موضوع الشكوى:

• تحصل الإصدارات ذات الأرقام الزوجية من .NET على ثلاث سنوات من الدعم طويل الأمد المجاني (LTS)
• تُعدّ الإصدارات ذات الأرقام الفردية إصدارات قياسية (STS) وتُدعم 18 شهراً فقط
• يرى المطور أن نافذة الثلاث سنوات لإصدارات LTS غير كافية للمؤسسات الكبرى
• الجدل ليس جديداً: فالشكوى من هذه السياسة تتكرر، وهي تُطرح الآن عبر issue جديد على GitHub وليس للمرة الأولى

لماذا تشعر المؤسسات بالاستياء من دورة التحديثات

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

وهذه الفجوة تحديداً بين وتيرة إصدارات Microsoft والسرعة الفعلية لتحديث الأنظمة المؤسسية كانت سبب الشكوى الجديدة على GitHub. ويشير صاحب الـ issue إلى أن شكاوى مماثلة من مجتمع مطوري البرمجيات المؤسسية تتردد منذ سنوات، لكن نموذج دعم المنصة لم يتغير جوهرياً.

ما الذي يُقترح تغييره

رغم عدم وجود مقترحات مقابلة محددة من Microsoft حتى الآن رداً على الشكوى، فإن عودة النقاش إلى الواجهة في issue علني على GitHub تُظهر أن نموذج الدعم غير المتماثل المعمول به، أي ثلاث سنوات للإصدارات الزوجية وسنة ونصف للفردية، لا يزال مصدر احتكاك بين وتيرة تطوير المنصة وممارسات اعتمادها في المؤسسات الكبيرة.

ما الذي يميز هذا عن المنصات الأخرى

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

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

ما الذي قد يحل المشكلة

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

ماذا يعني هذا

الجدل حول مدة دعم LTS في .NET ليس شكوى عابرة، بل موضوع يتكرر في مجتمع مطوري البرمجيات المؤسسية. وما دامت Microsoft تحافظ على نموذج «ثلاث سنوات للإصدارات الزوجية و18 شهراً للفردية»، فسيتعين على الشركات ذات دورات التحديث الطويلة أن تُدرج خطر انتهاء الدعم في خطط الترحيل لديها، أو أن تواصل السعي إلى مراجعة السياسة عبر قنوات علنية مثل GitHub.