-
Notifications
You must be signed in to change notification settings - Fork 177
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): Update dependencies and Docker images #614
base: main
Are you sure you want to change the base?
Conversation
87c59ba
to
aed7a8a
Compare
@reneleonhardt: Nice! Linked to: |
Thanks for looking into this. The way the changes are arranged makes it impossible to backport these to the currently maintained version 1.0.x. A lot of these changes make sense and are interesting though. |
aed7a8a
to
103c7a9
Compare
I can rebase onto main if that's what you mean by backport 😅 |
81a3b72
to
3b5a7f0
Compare
3b5a7f0
to
7ff2b4c
Compare
@mp911de Can you test this branch yourself and clarify what would be needed to merge updates? |
Hi @reneleonhardt , I think what Mark wants is something like atomic commits, you need to rebase with main and send commits that are independent of each other, to give an example you need to separate the changes in individual commits like:
More or less essentially the list you provide in the description, but each should be an individual commit rebased on top of main. BTW, normally when there are unrelated changes, the best thing is to send multiple PRs, but this also depends on the maintainer of the project if it's ok to have a single PR like this. |
Unrelated changes? Updates
Improve Tests
There will be a myriad of conflicts when any other PR get's merged before all of them are merged into main, what is the advantage of 10 commits changing 1 line over 1 PR changing 10 lines in the same file? |
Yes, unrelated changes, updating Maven Wrapper is not related and does not affect updating the dependabot configuration, and updating the tests is not related to building with JDK 17, and so on... I'm not a maintainer here but is just a good practice to make commits atomic, what this means is that if you update one part of the code that updates dependencies, that's one commit, if you update SCRAM code (including tests) that's another commit, in general changes that can live "independent" of each other should be different commits, there is no global "Updates" or "Improve Tests" category. What is the advantage of having 10 commits instead of a single one with all the changes mixed? |
Issue description
Additional context
There were no tests for PgPool, I just updated the Docker image.