So - I actually think the problem here is the Briefcase version, not the Python version.

Using an EOL Python is definitely a bad idea - but mostly because of security. Python 3.7 may be EOL, but it still works just as well as it did 8 months ago when it went EOL. That doesn't mean it's a good idea - but anyone trying to use Python 3.7 today is going to start seeing that they can't get the latest version of Pillow, Numpy, or any other major package with a binary component; even pure-Python projects will start adding minimum python requirements when they use new syntactic constructs (like match statements). Someone using Python 3.7 today is definitely making their life difficult, but it's not inherently a problem.

What is a problem is that they must be using a very old version of Briefcase. That means they're missing any number of features - but more importantly bugfixes, most importantly bug fixes introduced because the upstream tools have changed.

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

Unfortunately, there's no reliable release cadence for Briefcase at present. When we go "1.0", I'm expecting to move to calver, which will help - if you're running version 25.1 in 2026, you're likely on a stale version - but that doesn't help until we adopt calver. It also doesn't protect against "we don't do a release for a year".

The only other alternatives I can see would be:

1. Bake a "use by" date into the code, or
2. Probe PyPI to see if there's a newer release
3. Update the branch templates so they include a warning, or are unusable.

None of those are particularly attractive options to me; (1) is a management hassle; (2) is a network hit that slows down every user just so that a fraction of recalcitrant users (some of whom may have legitimate reasons for staying on old versions) can be warned. And the class of user that is going to get this warning is also the class of user that won't read the damn warning message :-) And (3) is a bit user-hostile for the (admittedly rare) use case of actually needing the old version.

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

I agree; I was using the Python version as a proxy for the Briefcase version. If you're using Python 3.7, you're going to have Briefcase v0.3.9 installed at best. Not perfect by any means but provides a good stopgap....and we already warn users about other bad practices.

As a funny idea....DNS requests are faster than HTTP requests. So, if you add a fake entry to beeware.org to return the version as an IP address, you can provide a bit faster "do i have the latest version" check 😜

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

I agree; I was using the Python version as a proxy for the Briefcase version. If you're using Python 3.7, you're going to have Briefcase v0.3.9 installed at best. Not perfect by any means but provides a good stopgap....and we already warn users about other bad practices.

I guess that's fair. It's imprecise, and we're still going to have the "people who need to read this are the people who won't read this" problem, but at least we'll have a big yellow warning message to point at.

As a funny idea....DNS requests are faster than HTTP requests. So, if you add a fake entry to beeware.org to return the version as an IP address, you can provide a bit faster "do i have the latest version" check 😜

Yeah... but then we're relying on DNS, and that always goes well 😝

Working on this at Pycon