-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Python version support #730
Comments
Running Note that this is for the last 30 days, and Flit 3.11 was only released on the 19th. Flit-coreDownload counts
Download proportions
Download counts (no Python 3.9 / Flit 3.10.1 outlier)
Download proportions (no Python 3.9 / Flit 3.10.1 outlier)
FlitDownload counts
Download proportions
Download counts (no Python 3.9 / Flit 3.10.1 outlier)
Download proportions (no Python 3.9 / Flit 3.10.1 outlier)
|
We still maintain a flit-core RPM in EPEL 8 (Python 3.6) which is supported until 2029 but not reflected in the PyPI statistics, so take that for what it's worth. |
By 2029 Python 3.13 will be end-of-life! Does your package attempt to update to new versions of flit(-core)? I imagine it would be fairly easy to patch out 3.9+ features (we won't be using match/case soon), but my personal opinion would be not to factor downstream redistributors into the support decision -- they have their own policies for their own audiences. A |
Thanks, that's good to know about, though we're not likely to keep supporting Python 3.6 upstream for another 5 years. What's your general plan when packages drop the Python version you're on? I think I'm already something of an outlier in maintaining support for as long as I do (compare Numpy's policy), so you've presumably had this for a lot of packages already. Do you stick with an old version and try to backport specific changes that seem important enough? Or do you take newer versions and modify them to get around compatibility issues? Or a mixture? |
Definitely. I just wanted to point out that there were other people still using 3.6.
Generally, we avoid updating Python libraries in stable releases unless there's a strong reason to do so (e.g., security fixes, major bugfixes, and update that's needed by another package, user-requested features that don't come with other incompatible changes). By the time an upstream drops compatibility for the Python version we are using, we usually just manually backport specific changes, but this is not always straightforward. |
Originally posted by @takluyver in #728 (comment)
Flit 3.11 supports Python 3.8+, and flit-core supports 3.6+.
Latest statistics 1 for flit-core downloads for show that 3.6 represents <0.05%, 3.7 represents <0.1%, and 3.8 <2%. 3.9 is the overwhelming majority at >50%.
For flit 2, Python 3.9 is again the overwhelming majority with >80%. The numbers are a little suspicious as 3.9 specifically skyrockets from late October/November onwards. I will try to look at a more granular level.
This probably suggests that dropping 3.6 and 3.7 for flit-core is a reasonable move, but other than that Flit should maintain support for non end-of-life Python releases.
A
The text was updated successfully, but these errors were encountered: