-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
adding python 3.10 [tag & CI] #428
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
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.
Looks good.
Might be good to test 3.12-dev as well, to make sure things here are ready, and also to help test CPython itself before the big release in October.
sure, just would make it in separate PR to keep this change focus... 🐿️ |
Hello @dbieber, could you pls check and approve running CI... 🐿️ |
Thanks for the PR.
|
ok, so lets do it one by one 🐿️ |
What's the significance of the squirrel emoji? |
Nothing special, just mood at the moment, but I can remove it if you wish 🦦 |
Anyways, it seems that the CI is also failing for py3.8, which was untouched in this PR, so maybe something on master? Maybe worse to implement version freeze? |
Not at all! Was just curious. 🐙
Yes, looks like an update to the linter. #430 addresses. But 3.7 is also failing, and that looks like a linter bug, not a fire one! |
#433 is merged, ready for rebase/update here. |
@hugovk would it be possible in the setting to enable:
|
It would, but I'm not a member of this project :) For auto-merge, we'd need to mark some status checks as required. The CLA is an obvious choice. For the CI, it can be tedious having to click through in the admin settings to mark each individual Python version as a required check; and then when adding/dropping versions, having to go back and repeat. A common solution is to add a final noop job, which depends on the main test matrix job. And then only that final success job needs to be added as a required check. For example: |
yes I did it too but I think your job won't reflect skip/cancel event, see: |
Restrict change to version; defer trigger changes for future consideration
I merged the version change (CI for 3.10). |
I believe that Fire is fully compatible with all new Python versions so: