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
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:
~> 1.2is shorthand for
~> 1.2.3is shorthand for
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.
In the example above,
gemmit is expressing that it wants functionality released in version
fuzzin needs functionality introduced in
By virtue of semantic versioning, we can be reasonably assured that version
awesomesauce doesn't break functionality from its
2.1.0 version. So why is
gemmit restricting to
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.