[Rubygems-developers] The case of binary gems and Ruby versions.

Charlie Savage cfis at savagexi.com
Fri Apr 17 00:10:20 EDT 2009


> 
> What about adding officially support for gem-name-version-RUBY_VER-PLATFORM.gem

I agree with Luis's proposal.  It has some nice benefits:

* Its fairly clear how it works
* Its builds on a precedent already set by ruby gems (i.e., include the
platform name in a binary gem name)
* It doesn't add any additional burden on gem developers
* It conceptually makes sense in that my-gem-1.8-mswin32 is a different
gem than my-gem-1.9-mswin32 or my-gem-1.8-linux.

In contrast, the idea of having a single gem containing multiple
binaries seems a more difficult road to go down.  How would the right
gem get loaded?  How would that work across Ruby versions?  How would it
work across all OSes?  What binaries would get included?  Is this per
platform (so 1.8 windows gem and 1.9 windows gem) or per ruby version
(1.8 windows gem and 1.8 linux gem)?  How would a gem developer manage
to actually build such a gem with multiple binaries in it (seems like it
could be tricky to setup the right build environment).  What if you
decide to stop supporting Ruby 1.8 - how would a Ruby 1.8 installation
realize it has to pull version 1 of your gem but not version 2?  Etc., etc.

And out of curiosity, is there a precedent of a packaging system making
this choice (I guess COM with multiple interfaces - but that didn't work
so well)?

Obviously versioning is a near impossible problem to solve, so there
probably isn't a "perfect" answer, but option #1 seems more appealing to me.

Thanks,

Charlie


More information about the Rubygems-developers mailing list