"Chad Woolley" <[EMAIL PROTECTED]> writes:
>> or possibly, as each {major, minor, minor_minor, tiddler} may be
>> regarded as an int:
>> Version 2.2.0.-99
>
> I believe this is essentially what Josh, Alex, and Phil are going to
> do, but by using a non-numeric number rather than a negative number to
> indicate the prerelease status, with the addition of a flag to force
> install of a prerelease gem.
This is was sort of how it originally implemented, but with 2.2.0.a
becoming [2,2,0,-1,'a'] behind the scenes for sorting purposes. There
were some issues with a few edge cases, and Josh replaced it with new
logic. I'm not sure of the details as to why; would have to ask him
about it.
> I initially thought this was a bad idea, especially since the current
> Rails approach works fine, as long as you are not hung up on your
> first public release ending in zero.
>
> However, the thing that immediately convinced me otherwise - I'm very
> pragmatic ;) - is that this would allow ANY prerelease gem to be
> pushed to rubyforge, and people would not automatically pull it down,
> because the default would be to NOT download any prerelease gems.
Yes, this would reduce the need for projects to run their own gem
servers. Some large ones still might want to in order to reduce the
delay in pushing out to a number of mirrors, but it levels the playing
field a bit for smaller projects.
> 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.
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?
-Phil
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
