[Rubygems-developers] The case of binary gems and Ruby versions.
djberg96 at gmail.com
Thu Apr 16 22:53:29 EDT 2009
Luis Lavena wrote:
> On Thu, Apr 16, 2009 at 11:07 PM, Jeremy Hinegardner
> <jeremy at hinegardner.org> wrote:
>> On Thu, Apr 16, 2009 at 05:44:30PM -0700, Ryan Davis wrote:
>>> On Apr 16, 2009, at 16:15 , Eric Hodel wrote:
>>>> I see two solutions:
>>>> Package two separate gems with an indicator in the name for 1.8 vs 1.9
>>>> Package a gem with both libraries inside, and add something to
>>>> require_paths for 1.8 vs 1.9
>>> package the gem normally (but specifying what version of ruby should be
>>> mandatory) and when it uploads it goes to a versioned depot. pure ruby gems
>>> go up to a shared depot, binaries go to a versioned one. gem fetch can deal
>>> with this since it has the spec already. I think this should be
>>> transparent... NOT as another gem source.
>> This was my thought too. Solve this in the repo. Instead of having
>> Or something along those lines.
> I agree with both, this should be solved from the server perspective, however:
> 1) I cannot generate both 1.8 and 1.9 cross compiled gems from my
> package in an automated way, since the gem will override the previous
> generated one.
I think this is solvable with a Rake task. I know it's a bit of a pain,
but it's not _that_ bad.
> 2) When upload the file to rubyforge (either web-based or rubyforge
> gem) I cannot upload 2 files with the same name.
This will be a problem, and we'll have to get Tom involved. On the "Add
Release" screen we'll need to add a "Ruby Branch" drop down menu. So
long as the same branch isn't re-used, it should work.
Personally I'd be in favor of replacing the "Processor" drop down, as it
is completely useless as far as I can tell.
More information about the Rubygems-developers