-
Notifications
You must be signed in to change notification settings - Fork 3
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
chore(deps): Bump all dependencies #252
Conversation
a0c6adb
to
62e4e01
Compare
Not that what you did is wrong, but what I often do is just take over an existing dependabot PR. It makes it a bit easier, as you only have to fix what is wrong, instead of recreating it. It also means it has the history of what versions got bumped etc. What is important to check versions that had major-version updates, to see what they were about. For example aiohttp 3.11 drops Python 3.8 support. Some parts of our software stack might still use 3.7, although most got bumped to 3.10. But more importantly, sometimes software like aiohttp changes parameters or something, making the software not work. But this isn't really noticeable in cases where we don't have a preview (like with dibridge), so we can't deploy it on staging. For most other projects that do have a staging, adding the "preview" label to the PR is enough to start that deployment. That way you can test if it actually works or not. Which is the ultimate validation of a PR :) The only thing in the list of bumps that really stands out, is |
|
90d29ca
to
ec55843
Compare
My method was:
I imagine all the "unnecessary" libraries and older versions are due to the older python version (which I used as it's what's used in testing) |
0374612
to
7de5cf3
Compare
7de5cf3
to
8486934
Compare
Trying it myself, as dependabot apparently doesn't like when there are new dependencies-of-dependencies added? There's probably a better way of dealing with this with dependabot, but IDK what it is
Closes #251