On Thu, Apr 16, 2009 at 11:07 PM, Jeremy Hinegardner <jer...@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. 2) When upload the file to rubyforge (either web-based or rubyforge gem) I cannot upload 2 files with the same name. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
