On Tue, Nov 11, 2008 at 11:59 AM, Phil Hagelberg <[EMAIL PROTECTED]>wrote:
> Ryan Davis <[EMAIL PROTECTED]> 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
_______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
