fix python version to allow 3.14.* (anything <3.15)

[n2ygk]

testing for <= 3.14 breaks on minor releases like 3.14.2

Description of the Change

Fixed pyproject.toml to test for <3.15

Checklist

• PR only contains one change (considered splitting up PR)
• unit-test added
• documentation updated
• CHANGELOG.md updated (only for user relevant changes)
• author name in AUTHORS
• tests/app/idp updated to demonstrate new features
• tests/app/rp updated to demonstrate new features

[n2ygk]

@dopry not clear to me how uv.lock gets updated. I tried uv lock but it didn't change. Is this lock file even supposed to be checked in to the project?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[hugovk]

Hello, Python 3.14 and 3.15 release manager here! 👋

I strongly recommend against an upper cap.

First, by disallowing installation on 3.15 (currently in alpha), you're preventing people testing their own code on 3.15. I would really like people to be able to test their code on 3.15 to find and report bugs in Python so we can fix them before the big release in October. Also to help prepare their own code for 3.15.

Not only those who depend on django-oauth-toolkit, but those who depend on dependencies of django-oauth-toolkit. And so on down the chain.

But more importantly, it's too late to add any top version here, you would have needed to do it from day one (or else need to yank or delete all past releases!).

For example, if you release django-oauth-toolkit 3.2.0 with <=3.15 and I try and install with Python 3.15, I'll get the last version available without the top pin, 3.1.0.

Fast forward a year or two. Maybe you have <=3.17, and have released django-oauth-toolkit 5.1.0 or something. I try and install with 3.17, and end up with 3.1.0 from way back in 2025, which is definitely not intended.

See https://iscinumpy.dev/post/bound-version-constraints/ for the long version.

[n2ygk]

@dopry over to you for your review of the suggestion not to set an upper bound on requirements. Testing versions will continue to need to be update as new python releases are publshed.

[dopry]

@dopry not clear to me how uv.lock gets updated. I tried uv lock but it didn't change. Is this lock file even supposed to be checked in to the project?

It gets updated anytime you run uv sync iirc

[dopry]

@hugovk thanks for the tip!

[hugovk]

(At some point you could drop Python 3.8 and 3.9: https://devguide.python.org/versions/)

[dopry]

@hugovk always happy to drop versions.

I understand your desire, as a release manager, to have users testing on latest python versions. As a maintainer of a contributed module, I don't want users running code on python versions I haven't validated, so I don't get a bunch of support requests I don't have the resources to address. I don't want to advertise module as supporting something unless I have validated it. Poor experiences like that will reflect negatively on the module's quality. I feel there should be more focus on getting package maintainers testing and running CI against python latest and nightly. If you want more testing on 3.15 and latest we should lobby GitHub, CircleCI, et al to ensure they make those python versions available for testing. I would be more than happy to setup a tox environment for latest, and even have it report failures back to python org infrastructure to provide signals that could give upstream insight the effects of changes.

[hugovk]

I understand your desire, as a release manager, to have users testing on latest python versions.

👍

As a maintainer of a contributed module, I don't want users running code on python versions I haven't validated, so I don't get a bunch of support requests I don't have the resources to address.

I think there's a difference between advertising support (for example, via documentation and Trove classifiers) and actively blocking people from testing a pre-release.

If you get a support request for a version you don't advertise as supporting, you're well within your rights say it's not yet supported.

I don't want to advertise module as supporting something unless I have validated it. Poor experiences like that will reflect negatively on the module's quality.

Agreed.

I feel there should be more focus on getting package maintainers testing and running CI against python latest and nightly. If you want more testing on 3.15 and latest we should lobby GitHub, CircleCI, et al to ensure they make those python versions available for testing.

Yes, the good news is GitHub already has the ~monthly 3.15 pre-releases available (like this).

For nightly, please add a 👍 to actions/setup-python#31

I would be more than happy to setup a tox environment for latest, and even have it report failures back to python org infrastructure to provide signals that could give upstream insight the effects of changes.

Sounds good, thank you :)

[dopry]

As a maintainer of a contributed module, I don't want users running code on python versions I haven't validated, so I don't get a bunch of support requests I don't have the resources to address.

I think there's a difference between advertising support (for example, via documentation and Trove classifiers) and actively blocking people from testing a pre-release.

As a developer, if a pip install <package name> installs a package on python 3.15, then my impression is that is should be working on 3.15. If as a developer, I want to work with unstable prerelease packages, I want to specify that. I don't want to cross reference classifiers and specify versions every time I install a package to make sure it's going to work.

As a maintainer, I can publish prerelease versions with relaxed constraints for people who want to test at the bleeding edge.

If you get a support request for a version you don't advertise as supporting, you're well within your rights say it's not yet supported.

I would prefer to pre-empt them, so I don't have to spend my time doing that. Also, I don't like telling users things that may come across as dismissive of their unmet expectations.

I feel there should be more focus on getting package maintainers testing and running CI against python latest and nightly. If you want more testing on 3.15 and latest we should lobby GitHub, CircleCI, et al to ensure they make those python versions available for testing.

Yes, the good news is GitHub already has the ~monthly 3.15 pre-releases available (like this).

Awesome I'll look into it.

For nightly, please add a 👍 to actions/setup-python#31

done.