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 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
