How fresh are your gems? | Hacker News Reader

How fresh are your gems?

jonathannen.com

41 pointsjwilliams17 comments

Or just install the prerelease of bundler (`gem install bundler --pre`), which works well enough that Heroku uses it for slug compilation, and run:

  bundle outdated

I mistakenly thought that was a deprecated feature, but I've taken a look. Not getting the same results at the moment (1.1 won't let me update at all at the moment), but I'll see if I can merge/collaborate. Thanks for the pointer.

That also confused me. It is in the docs but not in the code yet (see: https://github.com/carlhuda/bundler/issues/1401 )

There's a cool site here http://www.bundlewatcher.com/ that can read your bundle definition and provides a RSS feed of updates to all your gems.

I have all my gems locked on specific versions to avoid surprises, and this site shows me when there are updates and I can decide to update my bundle to use the updates.

Thanks - That looks pretty interesting. I'll give it a shot.

Thanks! I was planning to do this, but now I can just use it.

hmm it just throws an error for me when I call gemfresh

Happy to take a look - Can you raise an issue at: https://github.com/jonathannen/gemfresh/issues

If you can, include the stack and the output of `gem environment`. Plus (if they are public) the links to the Gemfile and Gemfile.lock.

Is this an issue for people?

I have bundle update as a part of my build/release process, if things break, I either update, or freeze the version.

How do other people deal with this?

Doesn't keep me up at night, but it was something I was doing manually and I thought better off scripted. Even with fuzzy/handwave "~> 1.1.1" specifications you can end up off the most current version. I've got a handful of projects on the go and as a rule I don't like to let them go stale.

but, just simply leaving the version number blank, "bundle update" will get the latest. correct?

Yes, that's correct.

Personally I always assign the working version numbers to the Gemfile. What happens in say a years time when you're meant to come back and maintain the site? New versions could mean a drastically broken system and you won't be maintaining a contracts codebase if you are not getting paid to do so.

The .lock file will have the versions that are currently bundled, so you can always check what versions are bundled there. But I guess that requires a bit of messing around, where as what you do seems quite straight forward.

Yes but if the repository is cloned with a lock file, when you bundle install, the lock file is then updated with your new gem versions if you have not specified a specific gem version number.

not to labor the point. But the lock file is in the repo, it doesn't matter if it's updated, there is a version in the repo.

if a newer version breaks, then I pull the older version into a local directory ("vendor/mine") and use :path directive in my gemfile

Why not just put an explicit version number directly in the Gemfile. Seems easer than vendoring the gem and bloating the repo (unless you're worried about old versions being yanked from rubygems).

Reply on news.ycombinator.com