Changes/Django 5x

Django 5.x

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Update the default Django stack in Fedora from 4.2 to 5.x

(Note: 5.2 is scheduled to be released in April so F42 might initially ship with 5.1)

Owner

• Name: Michel Lind, Neal Gompa, Carl George
• Email: michel@michel-slm.name, ngompa13@gmail.com, carl@redhat.com

Current status

• Targeted release: Fedora Linux 42
• Last updated: 2024-12-18
• [Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

This change will update Django in Fedora to the latest upstream release, clean up some packaging tech debt, and avoid confusion where in the past, python-django4.2 was newer than python-django for a period.

Similar to the packaging approach for the Python interpreter itself, we're moving to a single source RPM for each Django major version. The major version initially shipped with a given Fedora release will have unsuffixed binary packages (e.g. python3-django) while any newer or older versions will have suffixed binary packages (e.g. python3-django5). Suffixed packages (source and binary) will only list the major version (so python-django5 instead of python-django5.1).

Benefit to Fedora

This change makes the Django packaging in Fedora consistent with that in EPEL, where due to lifecycle considerations, for EPEL 8 and above we only package python-django3 and python-django4.2 instead of python-django, allowing them to be retired if they are EOL upstream and there are serious security issues.

Django itself takes backward compatibility seriously, and within a given major version, minor versions only drop features that are already deprecated in the previous major version. That being said, because only X.2 releases are LTS releases, this approach let us move fast and introduce the latest Django major version without affecting those on the 'default' version that ships at the time of release.

Users can swap out Django versions as they please among the different supported versions, as the packages are designed to be swappable.

Lastly, some packaging remnant from the time where Django provides both Python 2 and Python 3 packages will be dropped - e.g. the aliases for django-admin will be removed.

Scope

• Proposal owners:
  • introduce python-django5 for all Fedora releases (default for F42+, versioned for older releases)
  • retire python-django from Fedora
  • audit packages that explicitly depend on python3-django and file bugs requesting they change to use the automatic Python dependency generators or explicitly depend on python3dist(django)

• Other developers:
  • if your package explicitly depends on python3-django, change to use the automatic Python dependency generators or explicitly depend on python3dist(django). This is optional but will let your package runs against alternate Django versions and rebuildable in EPEL
  • help test switching between Django stacks
• Release engineering: #12507

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with the Fedora Strategy:

User Experience

End users will mostly not be affected - installing python3-django as before will just work. The suffixed django-admin launcher scripts are going away, but the change owners believe the usage of these is minimal to non-existent - they just denote the version of the Python runtime, and we have not released Django for anything but the base runtime ever since we stopped building for Python 2.7.

Dependencies

None that would be affected; a dependency check with fedrq indicates that some packages are hardcoding dependencies on python3-django, which should be fixed for EPEL, but because in Fedora we will keep shipping unversioned binary packages they won't be affected

$ fedrq whatrequires python3-django -F "multiline:source,requires" --notsrc | grep django | grep -v 'python3.13dist(django)' | grep python3-django
osh : python3-django >= 3.2
python-django-ajax-selects : python3-django
python-django-angular : python3-django
python-django-annoying : python3-django
python-django-authority : python3-django
python-django-database-url : python3-django
python-django-filter : python3-django-rest-framework
python-django-formtools : python3-django >= 1.7
python-django-health-check : python3-django
python-django-ipware : python3-django
python-django-pipeline : python3-django
python-django-pytest : python3-django
python-django-redis : python3-django
python-django-reversion : python3-django
python-django-rules : python3-django
python-django-tagging : python3-django
python-django-tastypie : python3-django
python-django-threadedcomments : python3-django
python-mozilla-django-oidc : python3-django

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?)

Change owners will update the existing python-django package to 5.x

• Contingency deadline:

Beta freeze - whenever the deadline is for retiring the old python-django package

• Blocks release?

No

Documentation

N/A (not a System Wide Change) A README.Fedora describing the maintenance process will be included in the new python-django5 package and copied into other versioned packages (right now python-django4.2) when they are updated or created

Release Notes

N/A