Django в этом году отметил 20-летие. За это время текущий график релизов доказал свою эффективность, но возникают вопросы:
☹️ Номера версий мало что говорят. Видя Django 2.2, сложно понять, когда он вышел и насколько устарел.
☹️ Версии выглядят как семантические (x.0), но на деле не содержат серьёзных изменений. Например, Django 6.0 почти не отличается от 5.2 LTS.
Проблемы текущего цикла:
— Поддержка старых LTS-версий затрудняет обновления Python и создаёт нагрузку на CI.
— Разработчикам сторонних пакетов приходится поддерживать старые версии дольше, чем хотелось бы.
— Большая часть пользователей долго остаётся на неподдерживаемых версиях.
Решение — годовой цикл релизов:
✔️ Один крупный релиз Django в год, вместо одного каждые 8 месяцев.
✔️ Использование календарного версионирования: первая цифра — год, вторая — номер релиза.
✔️ Пример:
Django 2028.1 — первый релиз серии, 2028.2 — следующий.✔️ Каждый релиз получает 1 год исправлений багов и 2 года безопасности, то есть каждая версия будет фактически LTS.
✔️ Поддержка только актуальных версий Python (или плюс последняя «жёлтая»), что снижает нагрузку на CI и синхронизирует EOL Django с EOL Python.
Преимущества:
— Прозрачный и предсказуемый график релизов.
— Облегчённое обновление для компаний и пользователей.
— Каждая версия получает долгосрочную поддержку и безопасность.
— Возможность смелых изменений API без потери стабильности, особенно с инструментом
django-upgrade для автоматических обновлений кода.📌 Итог:
Предлагается внедрить годовой цикл релизов начиная с Django 7.0, с предсказуемой поддержкой Python и LTS для каждого релиза. Это улучшит обновляемость, снизит нагрузку на разработчиков и повысит долю пользователей на поддерживаемых версиях.
Что думаете?
🐸 Библиотека питониста
#буст