Drop support for Python 3.5 #1923
Conversation
| @@ -73,15 +73,9 @@ _base_envs: | |||
| python: 3.9 | |||
| after_failure: skip | |||
| python: | |||
| - 3.5 | |||
There was a problem hiding this comment.
FWIW having Travis integration dead in this repo for months, there's no need to care about updating its config. Hopefully, I'll be able to reintroduce a proper CI setup per the best practices I've developed over the last year or so.
| @@ -1,3 +1,8 @@ | |||
| v18.7.0 | |||
There was a problem hiding this comment.
This sounds like a breaking change. So maybe let's make it v19?
| v18.7.0 | |
| v19.0.0 |
There was a problem hiding this comment.
When I started dropping support for Python 2.7, I initially indicated a breaking change. Later, I noticed that thanks to python_requires, it's not really a breaking change as the packaging ecosystem maintains compatibility. By the same logic, adding a new dependency is technically a breaking change, but we don't treat it as one since the tooling handles it. My inclination is to stick with major change unless it's expected to require user intervention to account for the change.
| @@ -25,7 +25,6 @@ | |||
| 'License :: OSI Approved :: BSD License', | |||
| 'Programming Language :: Python', | |||
| 'Programming Language :: Python :: 3', | |||
| 'Programming Language :: Python :: 3.5', | |||
| 'Programming Language :: Python :: 3.6', | |||
| 'Programming Language :: Python :: 3.7', | |||
| 'Programming Language :: Python :: 3.8', | |||
There was a problem hiding this comment.
Not sure if this belongs in the current PR but we also need to add a specifier for 3.9
| 'Programming Language :: Python :: 3.8', | |
| 'Programming Language :: Python :: 3.8', | |
| 'Programming Language :: Python :: 3.9', |
There was a problem hiding this comment.
This change has nothing to do with dropping support for Python 3.5. Honestly, I'd rather just remove these trove classifiers as they just add toil to my life.
There was a problem hiding this comment.
@jaraco I recently learned that Poetry generates these automatically from the value of python_requires. I wonder if setuptools could do the same.
There was a problem hiding this comment.
I also just remembered that CherryPy docs mention somewhere the min and the max supported versions that are retrieved from these specifiers: https://github.com/cherrypy/cherrypy/blob/main/docs/conf.py#L32-L41. So we need to keep them up-to-date at least for now.
There was a problem hiding this comment.
Definitely +1 for Setuptools to generate the classifiers automatically.
Python 3.5 is EOL. Let's drop support for it.