Jan Krutisch, Co-Founder at Depfu

When a new version of a gem is released, Depfu looks up which projects use the gem and tries to update it. In the typical case of a Rails app with a checked in Gemfile.lock, there are basically two things that could happen at this point:

(Let’s assume we’re talking about the release of Rake 12.1.0)

A. You have either no version specified in the Gemfile, or the new version is within the specified version range:

gem 'rake'
# or
gem 'rake', '~> 12.0'

In this case, we only need to update the Gemfile.lock and see if the tests are still running after the update.

B. The new version is not within the specified version range:

gem 'rake', '~> 11.3'

Here, if we would want to update to 12.1.0, we’d have to bump the version range:

gem 'rake', '~> 12.0'

Up until now, this is exactly what we’ve done. Our reasoning was that even if you clamped down the versions, it might be worth a shot upgrading nevertheless to see if there are any obvious problems. Think of it more like a mid term todo item than something your team should act on immediately.

And then we got some feedback

We’ve heard from a number of our users that they think this is wrong. And they have a point: If you made the effort to actually specify a version range, chances are that you really don’t want to update the gem outside of that range.

Of course, it’s often not as simple as that. We’ve seen all sorts of reasons why teams lock versions - Sometimes they, after an upgrade of a gem, found some subtle bugs and didn’t have the time to fully investigate, so they roll back the upgrade and lock the version to a working one. And, as these things go, nobody ever gets back to do the actual investigation and so the dependency rot begins. So what happens if a security update comes in?

Also, as we’ve written earlier, we’re seeing a lot of projects where people specify version ranges out of habit (or because of wrong documentation on the gem docs) more strictly than needed. The following specification for example is, if we assume the project follows SemVer rules, too strict:

gem 'rake', '~> 11.3.0'

If a hypothetical 11.4 would come out, it would not match that version range, even though that’s probably not quite what the author had in mind.

But, since we’ve got so much feedback on this, we knew that we had to do something. We tried really hard to not make this a configurable setting, but so far, we haven’t found a smarter way.

What we have changed

So, today, we’ve actually made this our first user facing configuration option. You can decide wether you want Depfu to update gems even if their version is outside of the version constraints.

We’ve decided to keep all existing repos at the “old” behavior, meaning that Depfu would update gems outside of the constraints, mostly because we didn’t want to change existing behavior. In contrast, newly activated repos will get the “new” behavior and will only update to versions that match the constraints.

So if you’re reading this and you want the new behavior on your existing repo, you should head for the new repo settings screen. For that, log in to Depfu, go to the repo and click on the cogwheel icon.

An animation that shows how to set the setting

We’re currently thinking about ways to still distribute the information about the out-of-spec updates to you in a way that doesn’t look like an actionable item (like a PR does) to mitigate for some of the problems I’ve outlined above, and we’ll hopefully have news on that soon, too.