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