انتقد المطورون نافذة دعم LTS لثلاث سنوات من Microsoft لمنصة .NET

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

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

تقسم الخطة الحالية من Microsoft إصدارات .NET إلى نوعين بناءً على مدة الدعم، وهذه الخطة نفسها أصبحت موضوع شكوى:

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

لماذا المؤسسات غير راضية عن دورة التحديث

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

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

ما التغييرات المقترحة

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

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

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

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

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

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

ما يعنيه هذا

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