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

[Daniel Berger]

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
>>> or:
>>>
>>> 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
>>
>>    gems/
>>    latest_specs.4.8.gz
>>    ...
>>
>> Have
>>
>>    gems/
>>    gems/1.8/
>>    gems/1.9/
>>    latest_specs.4.8.gz
>>
>> Or something along those lines.
>>
>> enjoy,
>>
>> -jeremy
>>
> 
> 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.

Regards,

Dan