Giters

sidekiq-scheduler / sidekiq-scheduler

Lightweight job scheduler extension for Sidekiq

Home Page:https://sidekiq-scheduler.github.io/sidekiq-scheduler/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Address the Redis 5.0.0 deprecation warning

wscourge opened this issue · comments

commented

Pipelining commands on a Redis instance is deprecated and will be removed in Redis 5.0.0.

redis.pipelined do
  redis.get("key")
end

should be replaced by

redis.pipelined do |pipeline|
  pipeline.get("key")
end

(called from /usr/local/bundle/gems/sidekiq-scheduler-3.1.1/lib/sidekiq-scheduler/redis_manager.rb:140:in `block in register_job_instance'}

commented

This issue has been created many times, I wonder why no one uses the search functionality #366, #363, #358

Has already been fixed in #357, is available in the master branch, please point it to that branch in your Gemfile while no new release is made.

commented

Thanks @marcelolx, sorry for not searching this. When can we expect the release?

commented

In a few weeks. I strongly suggest to point in your Gemfile to the master branch of sidekiq-scheduler, this way you'll will be helping with testing the changes we've made.

commented

If you want people to test your code, I suggest you launch prereleases. I strongly doubt that any responsible person is going to deploy something you just called untested to their production environment.

My other suggestion is to release patches for small fixes such as the one reported in this issue - it is pretty obvious that this single fix will not break anything.

commented

If you want people to test your code, I suggest you launch prereleases. I strongly doubt that any responsible person is going to deploy something you just called untested to their production environment.

And what is the difference between a pre-release and pointing your Gemfile to the master branch (or v3-stable)? If you look at the v3-stable branch commits you will see that I have already bumped the version https://github.com/moove-it/sidekiq-scheduler/commits/v3-stable, I'm just waiting some days until I'll push the release to rubygems because I didn't have the time yet to make any tests.

My other suggestion is to release patches for small fixes such as the one reported in this issue - it is pretty obvious that this single fix will not break anything.

If it is obvious that it doesn't break anything, why do you don't want to point your Gemfile to the v3-stable branch then? It's literally the same with the difference that is not released yet in rubygems ¯_(ツ)_/¯

commented

I think the main difference is in the usage of bundle update command, especially when maintaining huge a codebase - tbh I have no idea how it works with the non-usual, parametrized gem setup, and whatever makes me put more effort in the common task I simply dislike.

To be clear, I'm just giving you a context of a person who uses gems a lot, while not necessarily diving into their code. I personally will wait for an actual release anyway. No hard feelings & keep up the good work.