gem-compare: Releasing a new gem version with confidence

What do you usually do when releasing a new version of gems? Running test suite? Something more? I like to use my tool on tracking changes in RubyGems gem-compare as it gives me a little bit more confidence on what am I actually releasing. Here’s how I do it.

Today I wanted to release a new version of fog-libvirt gem, so I checked out the sources, ran git pull, updated the version in lib, ran the test suite again and build the gem:

I was almost ready to gem push, but it’s always nice to get a little bit more confidence if we can. For instance I was unsure whether my .gemspec wasn’t broken or whether I didn’t merge a PR that changed permissions on files in an unexpected way. And for that we can use gem-compare, a RubyGems plugin to compare gems.

If you don’t have gem-compare plugin installed, you can install it by running:

With gem-compare I was are able to run the comparison of the old version (0.0.1 in this case) with the version I was about to release (0.0.2). gem-compare than went and compared the versions for me. This comparison includes RubyGems meta-data including dependencies, gem’s files including permissions as well as Gemfiles. Here is what it showed me before pushing a new version of fog-libvirt:

Note that I ran the gem compare command with -k switch. This is important here because the 0.0.2 version is not released yet and -k prefers to use already downloaded gems in the current directory.

Also note that gem-compare warned me about file permissions being set to 100664, because it expects them to be 100644. This is not a big deal and I am not sure what’s a better default so feel free to ignore that.

I hope that this tool can help you be a little bit more confident about what you release or what are you updating to. I already wrote a little bit about gem-compare on Medium, so you can go and read that piece too.

Leave a comment

Your email address will not be published. Required fields are marked *