gem "awesomesauce", "~> 1.2.3"

You're blindly copying the ~> x.y.z constraint into your .gemspec, aren't you? Shame on you!

You should be constraining to ~> x.y.

Wait, why?

Because the people using your gem are tired of seeing this:

Bundler could not find compatible versions for gem "awesomesauce":
  In Gemfile:
    gemmit depends on
      awesomesauce (~> 2.1.0)

    fuzzin depends on
      awesomesauce (~> 2.2.0)

Before I go any further, here's a quick glossary and refresher:

~> x.y.z

• ~> 1.2 is shorthand for >= 1.2.0, < 2.0.0
• ~> 1.2.3 is shorthand for >= 1.2.3, < 1.3.0

Semantic versioning

Enough gems adhere to semantic versioning that we can assume that it is the case. If they don't, we should be giving them crap for not!

• When a gem bumps the x.y.Z version: the only changes are (typically) bug fixes.

• When a gem bumps the x.Y.z version: new features are added, but existing features are not broken.

• When a gem bumps the X.y.z version: backwards incompatible changes were introduced.

Explain, already!

In the example above, gemmit is expressing that it wants functionality released in version 2.1.0 of awesomesauce. Similarly, fuzzin needs functionality introduced in 2.2.0.

By virtue of semantic versioning, we can be reasonably assured that version 2.2.0 of awesomesauce doesn't break functionality from its 2.1.0 version. So why is gemmit restricting to < 2.2.0?

Because the author didn't think about their users.

And now you either are stuck on old versions of gems that you don't want to be, or you are forced to patch the gemspec to loosen its constraints. Ugh.

For a pain free world, all we need is:

gem.add_dependency "awesomesauce", "~> 2.1"

Yeah, but what if I need to depend on a Z version?

So, depend on it! Nothing's stopping you from expressing more complex version requirements:

gem.add_dependency "awesomesauce", "~> 2.1", ">= 2.1.3"

The world thanks you for doing it.