[Rubygems-developers] Gem#status?

Eric Hodel drbrain at segment7.net
Thu Nov 13 15:26:27 EST 2008

On Nov 11, 2008, at 09:59 AM, Phil Hagelberg wrote:
> "Chad Woolley" <thewoolleyman at gmail.com> writes:
>> I'm really interested to see how they are going to do this without  
>> the
>> non-numeric versions breaking old versions of rubygems, but I'm
>> hopeful :)
> One thing we do is automatically check for prerelease versions when  
> the
> gemspec is built, and add the correct required_rubygems_version field
> where appropriate. But this is not a complete solution. It prevents
> prerelease gems from sneaking in, but it doesn't prevent old clients
> from trying (and failing) to install the prerelease where it should be
> trying to install the latest stable.
> The approach that Eric suggested was to exclude prerelease gems from  
> the
> "latest" source index and pull in the "full" source index when looking
> for prerelease gems.
> This is implemented, but there are some cases when we need the full
> source index but do not want prereleases installed. We can add guards
> for this in the next version of Rubygems, but I can't think of a way  
> to
> handle this for pre-1.4 clients using this strategy. The only  
> solution I
> can think of is to add a third source index for prereleases so they
> don't go into the full index *or* the latest index.

This could be a problem when looking for gems where a prerelease and  
actual release match and you are trying to install an older version.   
I haven't tested this scenario to see what happens, though.

Older RubyGems will treat a prerelease-versioned gem as having extra  

> As you can see, this is a bit of a hairy issue. But I think the status
> field that Daniel proposed would be subject to the exact same
> challenges when attempting to maintain backwards compatibility.
> Any ideas? Is adding a third index too drastic?

That could be a good solution, have a prerelease-only index to solve  
the backwards compatibility problem I mentioned above.  (If it is a  
problem, I don't know what older RubyGems do yet.)

More information about the Rubygems-developers mailing list