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
>> non-numeric versions breaking old versions of rubygems, but I'm
>> hopeful :)
> One thing we do is automatically check for prerelease versions when
> 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
> "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
> 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