Jan Krutisch, Co-Founder at Depfu

Ever since we started working on Depfu, we wondered if it would make sense to update the runtimes or, as we call it more generically: engines as well. Updating to a new Ruby or Node.js version is, very much like updating dependencies, an unloved chore with clear benefits when done regularly. Today we’ll start the beta test of this as a new Depfu feature.

On the surface, this feature doesn’t sound very complicated, but don’t be fooled. For dependencies, at least in the runtimes we support, there usually is a single (or double, if you count the lockfile separately) source of truth. For runtimes, things get complicated really, really fast. Even if you are using one of the version managers (Or, our new favourite, asdf-vm, the one version manager to rule them all), it’s not done by replacing the version number in .ruby-version, .node-version or .tool-versions. For ruby, a Gemfile could also specify a version (used by, for example, Heroku). For Node.js, the package.json can specify an arbitrarily complex version specificator in the engines compartment (of course it can, right?). What about your CI configuration? Do you use a Dockerfile to specify your base images?

Now in Beta!

The beta we’re launching today starts with support for the bare minimum of files to patch that sounded useful to us. Now we need to learn what other configuration files are important for you and where the patch strategies we’re initially starting with are falling over.

We’re starting with support for all three engines we’re supporting right now, so that’s Ruby, Node.js and Elixir. We support simple a Dockerfile, configs for CircleCI and Travis, and also, hopefully, a somewhat complete set of version manager configs for these three runtimes.

We’re also still pondering on how we can make it easier for 3rd parties (aka you!) to contribute to this. Do we need a generic, configurable way for you to support your overly specific hand crafted container config or would you rather directly contribute additional updaters if possible? This is an ongoing conversation but please tell us your ideas of course.

How you can test it

A screenshot of the Depfu engine updates configuration, showing the options described below

If you are already using Depfu, you can simply enable engine updates in the Depfu settings page. There are two settings, “Only Minor Engine Updates” and “Minor and Major Engine Updates” and these probably do what you expect: If you choose “Only Minor”, you will only get updates within your current major version line. If you choose “Minor and Major”, you will get updates for new major versions as well - As with normal dependency updates, the chances that something breaks spectacularly with those updates are higher, but if you treat the resulting pull/merge requests as the start of the update process, it may work for you.

We try to be somewhat smart with this, so for example, for Ruby, a project that doesn’t follow SemVer and instead treats major plus minor version as some sort of major version line, you will only get patch releases if you chose “minor”. It’s not your task to get caught up in nitpicky discussions about version semantics, right?

Halp!

Like I said, we need your help with this - if a config that stores an engine version in your repo is not properly updated it could be because of several reasons: Either we don’t support that file type yet or our updater’s way of patching the file content is way too naive. So please watch the diffs in these updates carefully and report any mistakes or missing files. And if you don’t feel like carrying that burden, that’s totally fine, too. Opting out can either be done via the project settings in the same way you turned the feature on or simply replying in the pull/merge request with @depfu pause - We’ll definitely let you all know as soon as we think that this feature is stable enough to not be called a beta anymore.