Gemnasium 2.0

This release marks the end of a big rewrite that lays the foundation of our vision for Gemnasium.

We really aim to make it an essential tool that will help developers save time dealing with dependencies so they can stay focused on their work. We keep hearing your feedbacks and will add more and more useful stuff in the future but this rewrite already comes with a bunch of new things and updates that you may take a look at.

New colors

The colors scheme has been redefined and now follows these rules:

green => dependency is up to date with latest version available

yellow => there is at least one newer stable version available

red => the dependency is behind a security fix or an important update (broken API, deprecation, …)

Why?

First, as app maintainers we eat our own dog food and after a long time using Gemnasium we ended to this new scheme which better suits our needs. It also answers most of our customers feedback about these status colors.

Having some outdated gems isn’t always a very bad thing: you may have missed the minor update about that feature you don’t use, so you’re behind latest. Well, yes but your app is still working great and there’s not threat on it. In such cases, the scary red was a bit too much.

On the other hand, staying just behind a tiny patch can be a very bad thing… you know, this little patch which fixes that big security issue! And here, red is a good color to say: “hey, you really should take a look and update me now”

How?

While green and yellow status updates will stay entirely automatic, the red one will now go through a manual process. For now, our team will take care of this by watching Rubygems updates and flag them as security or important update. Of course, this implies that we can’t do it for every Rubygems and only the most popular ones will be watched at first. But according to the Pareto principle, this should suit most of developers needs. We are also already working on alternative solutions to improve coverage.

Note: Prerelease versions will still be notified when published but they are no longer considered as a leading factor in dependencies status choice.

Locked version awareness

The more you tell to Gemnasium, the more it will show you in return!

If your repository contains a Gemfile.lock (aka lockfile), Gemnasium will now use it and check your dependencies against the versions that you really use in your application. This is a huge improvement and particularly for developers that heavily rely on Optimistic Version Constraint.

Say you have defined the following dependency requirement some times ago :

gem 'library', '>= 2.2.0' 

And now library 2.5.0 is out. Your requirement is still matching latest and any new install will get the 2.5.0 version.

But as an app user you certainly use a lockfile to ensure all your environments are using exact same versions of your dependencies. And then, unless you have updated it, you may have something like version 2.3.0 in your lockfile.

So your app is not using the latest version and this dependency is out-of-date! Now Gemnasium will warn you about this.

New badges

Ok they didn’t changed that much actually. The Travis-like style is really appreciated and developers are accustomed to it. So after some brush love and updated wording to match new colors meaning, here we go:

As an alternative, you still can use the dots version, available with just adding ?dots at the end of your badge url.

Gem versions history

Gem page now provides versions history so you can get a quick overview. This place will also receive some nice updates soon to provide you more useful information, so stay tuned.

New settings for personal notifications

The new settings section offers you the ability to choose the email address on which you want to receive personal notifications.

We also added “daily” and “never” frequencies in order to manage the notifications more finely or stop them for all your projects.

The new Hooks feature (available for business plans)

Email or Campfire hooks can now be defined on a per-profile basis that will be fired when a dependency is updated.

The hooks are totally separated from personal notifications, they have their own target (email address or campfire room) and their own frequency. Hooks are also shared among all users who can access the profile they belong to and all of them can add/update/remove the hooks.

We currently only provide Email and Campfire hooks, but feel free to suggest other ones if you need them!

In short

With all these new things combined together, you now have a great tool that will keep an eye on your dependencies 24/7 and warn you the way you want, when it matters to you.

We hope you’ll enjoy these changes and as always, your feedback is welcome!


blog comments powered by Disqus