Gemfile.lock

If you are responsible for an application, a last-mile application, not a library (a gem), please check in your Gemfile.lock.

I recently released rufus-scheduler 3.5.0 and it was quiet, a few new stars, no comments on RubyFlow. Ruby Weekly did not pick up the release in its announcement, so I thought I was free to focus on other things.

A couple of days later, I got notified on GitHub, people were posting on an old, closed, sidekiq-cron issue:

Great, if the API had changed, I would have been glad to release as 4.0.0 instead of 3.5.0, but since sidekiq-cron currently depends on rufus-scheduler >= 3.3.0, sidekiq-cron would still be "not scheduling".

The problem was again reported in two more issues, #199 and #201, it also just found its way on Stack Overflow.

How is the concern voiced?

I have been using sidekiq-cron successfully over the past few months, now it stopped working overnight. #201

and

Suddenly all of our cron jobs were not being enqueued anymore #199

OK, so suddenly it stopped working? You didn't check in your Gemfile.lock, that's what you're exposing yourself to.

It saddens me to see that everybody jumps at the "let's depend on rufus-scheduler 3.4 in our Gemfile" pseudo-solution. It might be necessary for new integrations of sideqik-cron, but for "running" deploys, it's poor practice.

If you are responsible for an application, a last-mile application, not a library/gem, please check in your Gemfile.lock, it is meant to protect you from that kind of problems.

Updating your dependency gem versions is something you do deliberately, with your back covered by your test suite.

(please note that I submitted a pull request to sidekiq-cron to rework the sidekiq-cron to rufus-scheduler dependency)