On Nov 11, 2008, at 09:59 AM, Phil Hagelberg wrote:
"Chad Woolley" <[EMAIL PROTECTED]> 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 zeros.

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

Reply via email to