[Rubygems-developers] Gem#status?

Chad Woolley thewoolleyman at gmail.com
Tue Nov 11 14:40:58 EST 2008


On Tue, Nov 11, 2008 at 11:59 AM, Phil Hagelberg <technomancy at gmail.com>wrote:

> Ryan Davis <ryand-ruby at zenspider.com> writes:
>
> >> * Version parts with letters are prerelease (e.g. 'a', 'b5', or
> >> RC1').
> >
> > the second you do this you're gonna get bugs filed saying that you
> > didn't sort the versions the way the user intended... how do you sort
> > a1' vs 'b5' vs 'rc1' vs 'z7'?
>
> Really? String#<=> is pretty well-understood as far as I can tell.
>

I agreed.  Standard ruby string comparison follows the principle of least
surprise.


> > For ruby2c, I released 1.0.0 beta 1-5 which I versioned as 1.0.0.1 to
> > 1.0.0.5. It seemed to work fine for me so far... I intentionally
> > didn't do any alphas or rc's etc. but I wanted to be clear that it
> > wasn't a clean 1.0.0 release.
>
> 1.0.0.1 looks like a very-minor increment on a 1.0.0 release. If I were
> to see that version available without reading through all the release
> announcements, I would have gone ahead and installed it. Any scheme that
> relies on users being thorough about reading the release notes is
> suspect in my mind.
>
> Also, issuing a gem update ruby2c would have pulled in this version,
> which is definitely not what users would expect. Did you keep it on a
> separate server?
>

Yes, 1.0.0.4 and 1.0.0.5 are on RubyForge (took a while to figure out that
it is Ruby*To*C, not ruby2c, but anyway).

This is also not a case that adequately illustrates the problems being
discussed, because there are no prior releases before these.  If there were
already some 0.9.x releases on rubyforge, this approach would make sense
(other than the fact that they are on rubyforge, more on that below), and be
similar to the current Rails 2.2 approach, assuming Ryan versions the
"final" 1.0 release as 1.0.1 or 1.1.0.

However, the difference is that these 'beta' gems were pushed to rubyforge,
whereas Rails is not going to push any prerelease gems to rubyforge.  This
is the problem Phil is talking about.  Unless users (or dependent gems) are
smart and/or diligent enough to manage their dependencies correctly and
pessimistically (which nobody is or ever will be), they will still
unknowingly pull down these "beta" gems if they are on RubyForge.

The proposed approach solves all these problems, except for the old rubygems
version's index problem. I think (not having looked at the code) a third
index for the new non-numeric versions is probably the safest and best way
to solve this in a way that will not break the world, but unfortunately
probably also the most work to implement properly.

-- Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20081111/4fe50999/attachment.html>


More information about the Rubygems-developers mailing list