Django ينتقل إلى إصدار سنوي بدعم 35 شهرًا لكل إصدار بدءًا من Django 2028.0
حين يصبح كل إصدار طويل الدعم يختفي الخيار الصعب بين الاستقرار والتحديث، ويصبح رقم الإصدار نفسه دليلًا على عمر النظام.
قبل مشروع Django مقترحًا باسم DEP 20: Annual Release Cycle، كتبه Carlton Gibson، يلغي فعليًا فكرة الإصدار طويل الدعم (LTS) عبر جعل كل إصدار إصدارًا طويل الدعم. وأعلن المشروع القرار على مدونته الرسمية في 10 أغسطس 2026. وسيكون أول إصدار في النظام الجديد Django 2028.0 في يناير 2028، بدلًا مما كان سيحمل اسم Django 7.0.
وفي النظام الحالي يصدر Django إصدارًا كل 8 أشهر، ولا يحصل على دعم لثلاث سنوات إلا إصدار واحد من كل ثلاثة. وهذا يضع الفرق أمام خيار صعب: البقاء على إصدار LTS وانتظار عامين، أو ملاحقة إصدار جديد كل 8 أشهر.
وفي هذا النظام تفصيل يغيب عن كثيرين. فمن يبقى على إصدار LTS لا يحصل على معظم إصلاحات الأخطاء (bugs)، لأنها تصدر على فرع الإصدار الحالي فقط. أي أن الاستقرار كان يأتي ومعه أخطاء غير مصلحة.
وفي النظام الجديد يصدر إصدار واحد كل عام في يناير، ويحصل كل إصدار على 35 شهرًا من الدعم: عام من الدعم الكامل، ثم عامان من إصلاحات الأمان وفقدان البيانات فقط. وفي أي وقت ستكون هناك 3 إصدارات مدعومة.
ويشرح المستند السبب: Python أصبحت تصدر مرة واحدة كل عام في أكتوبر، ودورة الـ 8 أشهر لم تكن تتوافق معها. ويضرب مثالًا بـ Django 4.2، الذي كان عند نهاية عمره ما زال يدعم Python 3.8، رغم أن دعم الأخيرة انتهى قبل ذلك بـ 18 شهرًا.
ويغيّر الترقيم بالتاريخ دلالة رقم الإصدار. فعبارة “نعمل على Django 2028” في عام 2031 تكشف عمر النظام مباشرة، بينما لم يكن رقم مثل 5.2 يقول شيئًا لمن لا يتابع جداول الدعم. وقد يدفع ذلك فرقًا كثيرة إلى إعادة النظر في خطط الترقية لديها.