Skip to content

Commit

Permalink
Drop support for Django < 4.2 and Python < 3.8
Browse files Browse the repository at this point in the history
  • Loading branch information
peterthomassen committed Apr 30, 2024
1 parent 91bbac1 commit 1f2daaf
Show file tree
Hide file tree
Showing 5 changed files with 9 additions and 35 deletions.
11 changes: 0 additions & 11 deletions .github/workflows/main.yml
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,6 @@ jobs:
strategy:
matrix:
python-version:
- '3.6'
- '3.7'
- '3.8'
- '3.9'
- '3.10'
Expand All @@ -37,18 +35,9 @@ jobs:
- name: Install dependencies
run: python -m pip install --upgrade codecov tox

- name: Install tox-py
if: ${{ matrix.python-version == '3.6' }}
run: python -m pip install --upgrade tox-py

- name: Run tox targets for ${{ matrix.python-version }}
if: ${{ matrix.python-version != '3.6' }}
run: tox run -f py$(echo ${{ matrix.python-version }} | tr -d .)

- name: Run tox targets for ${{ matrix.python-version }}
if: ${{ matrix.python-version == '3.6' }}
run: tox --py current

- name: Run extra tox targets
if: ${{ matrix.python-version == '3.9' }}
run: |
Expand Down
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,8 +53,8 @@ Some reasons you might want to use REST framework:

# Requirements

* Python 3.6+
* Django 5.0, 4.2, 4.1, 4.0, 3.2, 3.1, 3.0
* Python 3.8+
* Django 5.0, 4.2

We **highly recommend** and only officially support the latest patch release of
each Python and Django series.
Expand Down
4 changes: 2 additions & 2 deletions docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,8 +86,8 @@ continued development by **[signing up for a paid plan][funding]**.

REST framework requires the following:

* Python (3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12)
* Django (3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 5.0)
* Django (4.2, 5.0)
* Python (3.8, 3.9, 3.10, 3.11, 3.12)

We **highly recommend** and only officially support the latest patch release of
each Python and Django series.
Expand Down
13 changes: 3 additions & 10 deletions setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
from setuptools import find_packages, setup

CURRENT_PYTHON = sys.version_info[:2]
REQUIRED_PYTHON = (3, 6)
REQUIRED_PYTHON = (3, 8)

# This check and everything above must remain compatible with Python 2.7.
if CURRENT_PYTHON < REQUIRED_PYTHON:
Expand Down Expand Up @@ -83,27 +83,20 @@ def get_version(package):
author_email='tom@tomchristie.com', # SEE NOTE BELOW (*)
packages=find_packages(exclude=['tests*']),
include_package_data=True,
install_requires=["django>=3.0", 'backports.zoneinfo;python_version<"3.9"'],
python_requires=">=3.6",
install_requires=["django>=4.2", 'backports.zoneinfo;python_version<"3.9"'],
python_requires=">=3.8",
zip_safe=False,
classifiers=[
'Development Status :: 5 - Production/Stable',
'Environment :: Web Environment',
'Framework :: Django',
'Framework :: Django :: 3.0',
'Framework :: Django :: 3.1',
'Framework :: Django :: 3.2',
'Framework :: Django :: 4.0',
'Framework :: Django :: 4.1',
'Framework :: Django :: 4.2',
'Framework :: Django :: 5.0',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Operating System :: OS Independent',
'Programming Language :: Python',
'Programming Language :: Python :: 3',
'Programming Language :: Python :: 3.6',
'Programming Language :: Python :: 3.7',
'Programming Language :: Python :: 3.8',
'Programming Language :: Python :: 3.9',
'Programming Language :: Python :: 3.10',
Expand Down
12 changes: 2 additions & 10 deletions tox.ini
Original file line number Diff line number Diff line change
@@ -1,10 +1,7 @@
[tox]
envlist =
{py36,py37,py38,py39}-django30
{py36,py37,py38,py39}-django31
{py36,py37,py38,py39,py310}-django32
{py38,py39,py310}-{django40,django41,django42,djangomain}
{py311}-{django41,django42,django50,djangomain}
{py38,py39,py310}-{django42,djangomain}
{py311}-{django42,django50,djangomain}
{py312}-{django42,djanggo50,djangomain}
base
dist
Expand All @@ -17,11 +14,6 @@ setenv =
PYTHONDONTWRITEBYTECODE=1
PYTHONWARNINGS=once
deps =
django30: Django>=3.0,<3.1
django31: Django>=3.1,<3.2
django32: Django>=3.2,<4.0
django40: Django>=4.0,<4.1
django41: Django>=4.1,<4.2
django42: Django>=4.2,<5.0
django50: Django>=5.0,<5.1
djangomain: https://github.com/django/django/archive/main.tar.gz
Expand Down

13 comments on commit 1f2daaf

@auvipy
Copy link
Member

@auvipy auvipy commented on 1f2daaf Jul 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should revert this part and release 3.15.3

@TomNewChao
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, You are right. To resolve CVE-2024-21520, I upgraded django-rest-framework to 3.15.2, but django-rest-framework requires django to be installed later than 3.2.25, which forced me to upgrade django. This is really fucked up.

@peterthomassen
Copy link
Contributor Author

@peterthomassen peterthomassen commented on 1f2daaf Jul 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is that fucked up?

It primarily seems to be caused by the fact that you're using a Django version that's no longer maintained. If you're willing to not upgrade DJango and accept any security issues the Django installation might have, then why do you insist on upgrading DRF but not Django?

@TomNewChao
Copy link

@TomNewChao TomNewChao commented on 1f2daaf Jul 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is that fucked up?

It primarily seems to be caused by the fact that you're using a Django version that's no longer maintained. If you're willing to not upgrade DJango and accept any security issues the Django installation might have, then why do you insist on upgrading DRF but not Django?

Because I can't evaluate the risk points brought by upgrading Django from 3.25 to 4.2, and testing will increase extra workload, which is extra workload for solving the CVE vulnerability of Django-rest-framework, which I don't want to do; I just want to solve the CVE vulnerability of Django-rest-framework and don't want to upgrade now. Even if I need to upgrade, I hope to put a plan aside, it is urgent to solve the CVE vulnerability in time.

@peterthomassen
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I can't evaluate the risk points brought by upgrading Django from 3.25 to 4.2, and testing will increase extra workload

That just sounds like some technical debt has accumulated.

Dropping support for unmaintained Django versions is not just the above commit, but also other ones that remove extra code that had special treatment for those versions, reducing the size of the DRF codebase. I don't see why DRF folk should keep maintaining that only because updating Django is work.

You could argue that versions shouldn't be dropped silently in a minor release -- but it's not actually a silent change (the package manager will tell you about the requirements mismatch). (But for those who like to make this argument, consider the following: If we had released a new major DRF version (3.16) when dropping support for those old Django versions, then the CVE fix would have ended up in 3.16.1. So that would not have helped you: you still would not have the CVE fix and support for the old Django version at the same time. Any minor/major version discussion is thus besides the point in this case.)

@TomNewChao
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I can't evaluate the risk points brought by upgrading Django from 3.25 to 4.2, and testing will increase extra workload

That just sounds like some technical debt has accumulated.

There are more factors to consider when upgrading. If the upgrade does not bring me extra significant benefits, I may not upgrade.

Dropping support for unmaintained Django versions is not just the above commit, but also other ones that remove extra code that had special treatment for those versions, reducing the size of the DRF codebase. I don't see why DRF folk should keep maintaining that only because updating Django is work.

You could argue that versions shouldn't be dropped silently in a minor release -- but it's not actually a silent change (the package manager will tell you about the requirements mismatch). (But for those who like to make this argument, consider the following: If we had released a new major DRF version (3.16) when dropping support for those old Django versions, then the CVE fix would have ended up in 3.16.1. So that would not have helped you: you still would not have the CVE fix and support for the old Django version at the same time. Any minor/major version discussion is thus besides the point in this case.)

DRF follows the iteration of Django and Python versions, which is correct. I wonder if we can iterate the versions in the major version, including removing the versions that are no longer maintained in Django and Python, and fix CVE vulnerabilities in the minor version.

@peterthomassen
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the upgrade does not bring me extra significant benefits, I may not upgrade.

Upgrading to a maintained Django version would have brought the benefit of a compatible ecosystem. You're now asking DRF to put the work in instead. I think the right strategy would be to acknowledge that upgrading actually has the benefit you want, but you're not willing to put in the work on your side. That's OK, but your choice and not our problem.

I wonder if we can iterate the versions in the major version, including removing the versions that are no longer maintained in Django and Python, and fix CVE vulnerabilities in the minor version.

As I wrote earlier, if we had released 3.16 (instead of 3.15.2) on the occasion of dropping support for unmaintained Django versions, then the CVE fix would have gone into 3.16.1, not into 3.15.x. So you would be stuck with 3.15.1. Exactly as you are now.

@TomNewChao
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the upgrade does not bring me extra significant benefits, I may not upgrade.

Upgrading to a maintained Django version would have brought the benefit of a compatible ecosystem. You're now asking DRF to put the work in instead. I think the right strategy would be to acknowledge that upgrading actually has the benefit you want, but you're not willing to put in the work on your side. That's OK, but your choice and not our problem.

I wonder if we can iterate the versions in the major version, including removing the versions that are no longer maintained in Django and Python, and fix CVE vulnerabilities in the minor version.

As I wrote earlier, if we had released 3.16 (instead of 3.15.2) on the occasion of dropping support for unmaintained Django versions, then the CVE fix would have gone into 3.16.1, not into 3.15.x. So you would be stuck with 3.15.1. Exactly as you are now.

Why can't we release a new version to fix the CVE vulnerabilities in 3.15.x? Similar to the update version, only the CVE vulnerabilities of the current version or other additional bugs are maintained, which is conducive to the simultaneous update and iteration of multiple versions.

@peterthomassen
Copy link
Contributor Author

@peterthomassen peterthomassen commented on 1f2daaf Jul 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To quote from your earlier message, doing that (including the necessary testing and subsequent maintenance of two branches) "will increase extra workload, which is extra workload [...], which I don't want to do".

@auvipy
Copy link
Member

@auvipy auvipy commented on 1f2daaf Jul 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To quote from your earlier message, doing that (including the necessary testing and subsequent maintenance of two branches) "will increase extra workload, which is extra workload [...], which I don't want to do".

Tom Christie suggested this change, as the release was hastily done in a point release. not entirely your fault btw

@TomNewChao
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To quote from your earlier message, doing that (including the necessary testing and subsequent maintenance of two branches) "will increase extra workload, which is extra workload [...], which I don't want to do".

To quote from your earlier message, doing that (including the necessary testing and subsequent maintenance of two branches) "will increase extra workload, which is extra workload [...], which I don't want to do".

The reason why I have such a big opinion is that I have three services that have to upgrade the Django version due to the CVE vulnerability of drf. This is indeed a very tedious task for me. I believe that I am one of the many drf users, and the impact of this change is indeed very large.In short, we hope that drf will get better and better。

@browniebroke
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have three services that have to upgrade the Django version due to the CVE vulnerability of drf.

You don't have to upgrade Django because of DRF vulnerability. Today is DRF but tomorrow will be another django package. Sure, the patch release dropping support is not ideal, but package managers handle it just fine. You're running an unsupported version of Django, if you don't want vulnerabilities in your app, you should upgrade to a supported one, period.

I'm not a maintainer, just a mere user. I just don't want volunteer to do unecessary work, so I'm with Peter here.

@TomNewChao
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have three services that have to upgrade the Django version due to the CVE vulnerability of drf.

You don't have to upgrade Django because of DRF vulnerability. Today is DRF but tomorrow will be another django package. Sure, the patch release dropping support is not ideal, but package managers handle it just fine. You're running an unsupported version of Django, if you don't want vulnerabilities in your app, you should upgrade to a supported one, period.

I'm not a maintainer, just a mere user. I just don't want volunteer to do unecessary work, so I'm with Peter here.

Got it, I understand you, but we are just standing at different angles. We will evaluate the impact of upgrading the Django version and work hard to resolve it.Thanks to all the maintainers and fans of drf。

Please sign in to comment.