🐛 fix(pyproject-fmt): bump the newest Python the default names

[gaborbernat]

A project writing requires-python = ">=3.12,<3.16" says it runs on 3.15, and since 2.29.0 the formatter drops the classifier naming that release, as #460 reports. 🐛 Setting max_supported_python by hand puts it back, which is the workaround the reporter found.

Classifier generation reads the floor from requires-python and caps the result at max_supported_python, as the configuration docs describe. That cap named 3.14 while 3.15 sits at its release candidate, so it fell below what these files say they support and took the classifier with it. Whether a release exists is the question the cap answers, and a requirement cannot answer it, since <3.30 would otherwise name a dozen releases that have no classifier for PyPI to accept.

What let a stale number sit there is that nothing watched it, so both ends now move on their own. ✨ They stay written down in the source, and a run each day sets them from what is true that day. The newest has to satisfy two things at once, since either alone says too little: PyPI publishes a classifier naming it, and Python has published a release candidate. 3.16 has the first and not the second, so it names nothing yet, while a release still in alpha carries a classifier long before its behavior settles. The oldest is the release still carrying fixes, which 3.10 stops doing at the end of October.

Neither run writes down a date published ahead of time, nor compares against one, so a release that slips arrives when it arrives rather than on the day someone predicted. ✨ The seven places that spell either number move together, documentation included, and anyone naming max_supported_python themselves keeps what they set.

Bumping either end changes what the formatter writes, so the daily run opens a pull request rather than pushing, and whoever reviews it updates the expectations that name a release.

Fixes #460

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (2946fc3) to head (c94b2f8).

Additional details and impacted files

Flag	Coverage Δ
common	?
pyproject-fmt	100.00% <ø> (ø)
toml-doc	?
tox-rules	?
tox-toml-fmt	?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ulgens]

@gaborbernat Thank you so much for the quick fix. Tested and it worked.

I wasn't expecting it to be so complicated - does the underlying mechanism applies different logic for max_supported_python and requires-python? I was thinking that pointing them to the same code block would solve the issue but apparently the actual issue was a bit different. Also, do you know which commit / PR changed this behaviour in 2.29.0?

[gaborbernat]

Well, we're trying to have reasonable defaults here and support user expectations. This turned out to be a minor bug, but we used the opportunity to improve, stabilize, and automate much of this as part of this pull request, hence why it became a bit more complicated.