(incorporate carlwgeorge's suggestions) |
(announcing the change) |
||
| (5 intermediate revisions by one other user not shown) | |||
| Line 17: | Line 17: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAnnounced]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 35: | Line 35: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* [Announced] | * [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/DQ6DAONBVQVFJ4YBB6GXFSOANCPBAKIB/ Announced] | ||
* [ | * [https://discussion.fedoraproject.org/t/f42-change-proposal-django-5-x-self-contained/140617 Discussion thread] | ||
* FESCo issue: <will be assigned by the Wrangler> | * FESCo issue: <will be assigned by the Wrangler> | ||
* Tracker bug: <will be assigned by the Wrangler> | * Tracker bug: <will be assigned by the Wrangler> | ||
| Line 42: | Line 42: | ||
== Detailed Description == | == 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 | 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`). | |||
== Feedback == | == Feedback == | ||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
== Benefit to Fedora == | == 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. | 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. | 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. | ||
| Line 56: | Line 56: | ||
Users can swap out Django versions as they please among the different supported versions, as the packages are designed to be swappable. | 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. | 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 == | == Scope == | ||
| Line 68: | Line 67: | ||
** 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 | ** 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 | ** help test switching between Django stacks | ||
* Release engineering: | * Release engineering: [https://pagure.io/releng/issue/12507 #12507] | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
Latest revision as of 15:06, 24 December 2024
Django 5.x
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-24
- Announced
- 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).
Feedback
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-djangoand file bugs requesting they change to use the automatic Python dependency generators or explicitly depend onpython3dist(django)
- Other developers:
- if your package explicitly depends on
python3-django, change to use the automatic Python dependency generators or explicitly depend onpython3dist(django). This is optional but will let your package runs against alternate Django versions and rebuildable in EPEL - help test switching between Django stacks
- if your package explicitly depends on
- 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:
Upgrade/compatibility impact
Early Testing (Optional)
How To Test
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