Drop support for Django 4.2, Django 5.0 and Django 5.1

[p-r-a-v-i-n]

Note: Before submitting a code change, please review our contributing guidelines.

Description

Django 4.2 will reach end of support on April 30, 2026.

I’m opening this PR early so we can have enough time to plan, communicate, and prepare for removing support.

source: https://endoflife.date/django

[auvipy]

I want to wait until the release of django 6.2 LTS

[p-r-a-v-i-n]

I want to wait until the release of django 6.2 LTS

Okay

[Natgho]

Since it has been developed and stabilized, isn't it a terrible idea to discontinue support immediately? :)
https://endoflife.date/django
As @auvipy said, 4.2 should be supported until 2026.

[browniebroke]

Yes, a bit early for my taste.

I want to wait until the release of django 6.2 LTS

I don't think we need to wait until 6.2 (that's April 2027), but we should definitely wait until 4.2 reaches EOL, which is end of April.

[p-r-a-v-i-n]

I agree with you all here. I know this is way to early. My intention here was to make ourselves ready, to see any consequences. And once we reach at point where we are confident to drop support. We can do it without any rush.
Probably I already knew this response will come.
So if required I will turn this into draft.

[p-r-a-v-i-n]

Should we drop django 5.0 and django 5.1 as they both already reached to their EOL?

[browniebroke]

Should we drop django 5.0 and django 5.1 as they both already reached to their EOL?

Waw I didn't realise that they were... I think that makes sense, yes. We'll probably hold off merging this PR for a little bit anyway

[auvipy]

let us wait until atleast django 6.0 is released

[browniebroke]

let us wait until at least django 6.0 is released

I assume you mean 6.1? 6.0 has been out for a while 😄

[browniebroke]

We can also simplify these as django.VERSION >= (5, 1) will always be true:

django-rest-framework/rest_framework/compat.py

Lines 144 to 189 in 7f8ad25

	if django.VERSION >= (5, 1):
	# Django 5.1+: use the stock ip_address_validators function
	# Note: Before Django 5.1, ip_address_validators returns a tuple containing
	# 1) the list of validators and 2) the error message. Starting from
	# Django 5.1 ip_address_validators only returns the list of validators
	from django.core.validators import ip_address_validators
	def get_referenced_base_fields_from_q(q):
	return q.referenced_base_fields
	else:
	# Django <= 5.1: create a compatibility shim for ip_address_validators
	from django.core.validators import \
	ip_address_validators as _ip_address_validators
	def ip_address_validators(protocol, unpack_ipv4):
	return _ip_address_validators(protocol, unpack_ipv4)[0]
	# Django < 5.1: create a compatibility shim for Q.referenced_base_fields
	# https://github.com/django/django/blob/5.1a1/django/db/models/query_utils.py#L179
	def _get_paths_from_expression(expr):
	if isinstance(expr, models.F):
	yield expr.name
	elif hasattr(expr, 'flatten'):
	for child in expr.flatten():
	if isinstance(child, models.F):
	yield child.name
	elif isinstance(child, models.Q):
	yield from _get_children_from_q(child)
	def _get_children_from_q(q):
	for child in q.children:
	if isinstance(child, Node):
	yield from _get_children_from_q(child)
	elif isinstance(child, tuple):
	lhs, rhs = child
	yield lhs
	if hasattr(rhs, 'resolve_expression'):
	yield from _get_paths_from_expression(rhs)
	elif hasattr(child, 'resolve_expression'):
	yield from _get_paths_from_expression(child)
	def get_referenced_base_fields_from_q(q):
	return {
	child.split(LOOKUP_SEP, 1)[0] for child in _get_children_from_q(q)
	}

django-rest-framework/tests/test_middleware.py

Line 116 in 2ede857

@unittest.skipUnless(django.VERSION >= (5, 1), 'Only for Django 5.1+')

There are a few more in the codebase

[browniebroke]

There are also some leftover mentions of pytz in fields.py:

django-rest-framework/rest_framework/fields.py

Lines 33 to 36 in 2a910c8

	try:
	import pytz
	except ImportError:
	pytz = None

django-rest-framework/rest_framework/fields.py

Lines 1189 to 1190 in 2a910c8

	if pytz and isinstance(e, pytz.exceptions.InvalidTimeError):
	self.fail('make_aware', timezone=field_timezone)

[Copilot]

Pull request overview

This PR updates Django REST framework’s supported Django versions by dropping Django 4.2, 5.0, and 5.1, and aligns the codebase, test matrix, packaging metadata, and documentation with a new minimum of Django 5.2.

Changes:

• Update CI/test matrix and dependency groups to stop testing/installing Django 4.2/5.0/5.1.
• Raise the package minimum requirement to django>=5.2 and remove related compatibility shims.
• Remove remaining pytz-specific test/doc paths and make LoginRequiredMiddleware opt-out unconditional.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tox.ini	Removes Django 4.2/5.0/5.1 envs and dependency group entries from the tox matrix.
pyproject.toml	Bumps minimum Django to 5.2, removes old optional Django version groups, and drops pytz from test deps.
rest_framework/compat.py	Deletes Django<5.1 compatibility shims (e.g., IP validator and Q referenced field helpers).
rest_framework/serializers.py	Switches UniqueConstraint condition field extraction to Django’s referenced_base_fields.
rest_framework/fields.py	Moves IP validator import to Django core; removes pytz-specific DST handling code path.
rest_framework/views.py	Always sets view.login_required = False (no longer version-gated).
rest_framework/viewsets.py	Always sets view.login_required = False (no longer version-gated).
tests/test_viewsets.py	Removes Django-version-gated skip; asserts login_required behavior unconditionally.
tests/test_views.py	Removes Django-version-gated skip; asserts login_required behavior unconditionally.
tests/test_middleware.py	Removes Django-version-gated skip so LoginRequiredMiddleware compatibility tests always run.
tests/test_fields.py	Removes pytz-based DST test class and updates timezone-related test text.
README.md	Updates stated supported Django versions to 5.2 and 6.0.
docs/index.md	Updates stated supported Django versions to 5.2 and 6.0.
docs/api-guide/fields.md	Updates DateTimeField.default_timezone docs to remove pytz mention.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[browniebroke]

Ah, yes good point. Would you mind addressing this?