Avoid redis 5.x deprecation warning when closing connection #376
Conversation
There was a problem hiding this comment.
Hey @sevdog. Thanks for this. Looks sensible.
Q: Do we need to add testing for the different versions of redis-py? (Perhaps just for the main tests?)
I was not sure about this point, now that you are pointing it I think it would be fine to have in the CI/tox configuration also the matrix of supported redis-py versions. In this way we may ensure compatibility and also mark such tests. What do you think? |
|
I think that might be helpful... — we could then easily test against (e.g.) current and upcoming versions, and perhaps be clearer/stricter about what versions we support. What's your take? Fancy adding it? 🎁 |
|
Taht could be nice! I think that a redis compatibility-matrix may be set-up in the scope of this PR. I would also like to add the same testing mechanism also for channels (since currently no version is pinned in setup, there is a generic statement in the changelog but nothing else). Maybe I could work on a PR which adds |
That would be perfect 🤩 Not sure we need Channels... but if you think so — Did it ever fail? 🤔 I don't think we need to test every combination of channels against every redis 🤔, and I'd just run the core tests, rather than all the sentinel and cluster ones. (It seems unlikely there's an extra regression there so saving a few cycles is probably better 🌳) |
|
Let me try to propose a test matrix:
Writing it down: redis compatibility is tested only against the latest release of channels and channels compatibility is tested only angainst the latest release of redis. |
|
That looks great |
Redis 5.0.1 adds a new method
acloseand deprecates theclosemethod in the async client.This change aims to resolve the deprecation warnings which arise when using the new redis-py until redis 4.5 is still supported.