-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Python 3.9 in continuous integration #110
Enable Python 3.9 in continuous integration #110
Conversation
.github/workflows/main.yml
Outdated
@@ -7,7 +7,7 @@ jobs: | |||
fail-fast: false | |||
matrix: | |||
os: [ubuntu-latest, macos-latest, windows-latest] | |||
python: [2.7, 3.5, 3.6, 3.7, 3.8, pypy3] | |||
python: [2.7, 3.6, 3.7, 3.8, 3.9, pypy3] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing 3.5 is a breaking change for frozen-flask, no matter the end of life. The policy is to follow whatever flask itself tests against. I'm inclined to releasing a breaking version, which would drop support for obsolete Python versions (opinions, @tswast?), but then let's do it properly. I quickly checked what versions are supported by flask and it seems they might have dropped even the 2.x line 😮
So my idea would be that we add support for 3.9 and release a minor version. Then we could prepare a version, which drops all the old stuff unsupported by Flask, and only then release a breaking version.
OK I now noticed that frozen-flask is version 0.15, so I'm not sure how closely it follows the semantic versioning scheme. I think a project used by ~2000 ppl and with history going back to 2011 deserves to take off with a "stable" v1.0.0, with which we could drop the old Python version, and from which we could follow with sem ver. Since I'm fairly new here, I'll wait for @tswast's opinions on all this. |
…-of-life)" This reverts commit f9592a5.
Ah, I just missed your latest comment before pushing changes. Will pause to hear the preferred approach. |
I think we can add 3.9 just fine, but we should sync on how to drop the old
stuff before doing that.
…On Thu 26. 11. 2020 at 17:10, James Addison ***@***.***> wrote:
Ah, I just missed your latest comment before pushing changes. Will pause
to hear the preferred approach.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#110 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACFGMNNKF7ESMLRFELBQ6DSRZ4YJANCNFSM4UD4NDXQ>
.
|
@tswast @honzajavorek Not urgent, but I'm wondering if there's been any further discussion about releasing an updated minor version of |
I may have missed it, but were there PRs to fix the library to support Python 3.9? Even without the 3.9 classifier in |
@tswast Yep; my understanding (which may have clouded over a bit since I last looked into this) is that #98 added Py3.9 compatibility, and since then #107 has fixed an incompatibility encountered when using Py2.7. To be thorough perhaps we should go back and discover when those test failures for Py2.7 began and understand that before a release; the issue relates to handling of multi-byte unicode characters in URLs. |
(taking a look into this now, to try to identify what initially caused the Py2.7 test failures) |
Ok, so the test was introduced a while back in b43242a in May 2011, and while it's neat that it uses Unicode everywhere, I think Python 2.7's |
Remove Python 3.5 continuous integration builds (it's now past end-of-life according to the Python download page)