On Nov 13, 8:26 am, "Luis Lavena" <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 10:22 AM, Trans <[EMAIL PROTECTED]> wrote:
>
> > On Nov 13, 6:13 am, "Luis Lavena" <[EMAIL PROTECTED]> wrote:
> >> On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger <[EMAIL PROTECTED]> wrote:
> >> > Josh Susser wrote:
>
> >> >> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote:
>
> >> >>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote:
>
> >> >>>> Really? String#<=> is pretty well-understood as far as I can tell.
>
> >> >>> yes... it is very well understood to be very bad for this problem:
>
> >> >>> >> "a2" <=> "a11"
> >> >>> => 1
> >> >>> >> 2 <=> 11
> >> >>> => -1
>
> >> >> So use a.1 and a.11 instead of a1 and a11
>
> >> >> def test_order
> >> >> numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ]
> >> >> versions = numbers.collect { |n| Gem::Version.new(n) }
> >> >> assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") }
> >> >> end
>
> >> > I can't say I like where this is going.
>
> >> > In my opinion this is going to lead to unforeseen issues. I don't know
> >> > what
> >> > those issues are exactly, I just have a very bad feeling about it.
>
> >> > I recommend holding off on this for now.
>
> >> > Regards,
>
> >> My guts tell me the same, but I guess is too late since several of
> >> these commits made to the trunk already.
>
> >> There is already a big nightmare (not to say gem hell) related to
> >> preview/rc gems laying in github or rubyforge that complicate the
> >> environment of many users (I get several reports about that). As
> >> example I can mention rspec gem depending on a patched version of rcov
> >> that only exist in github and has no binaries for it.
>
> >> Having that dependency buried and hidden from users make it hard to track.
>
> >> I believe pushing RC or preview versions to rubyforge will make "gem
> >> update" for several users a nightmare. As example, take gems that
> >> require compilation.
>
> >> Noone cares about this situation, but rubygems is dumb in this aspect,
> >> it will pick the latest version available with "ruby" as platform and
> >> try to compile it. If you lack the toolchain (either b'cause you're in
> >> a server or in Windows) you will make your environment bomb out and
> >> get lot of negavtive experiences from users.
>
> >> Previously, no RC or preview gem was published to rubyforge. Previews
> >> and RC where available through private gem servers to avoid this
> >> situation letting the developers control how and when these gems will
> >> hit the mirrors and made into the public.
>
> >> I don't see big OS distros like Ubuntu or even debian opening the room
> >> for RC and preview packages to their official distribution
> >> repositories.
>
> > I've occasionally seen pre-releases in the repositories.
>
> >> Anyway, just my PoV, this will also render useless patterns like "~>"
> >> and even worse dumb developers that do not check or maintain their
> >> dependency list properly.
>
> > I'm not sure why it's so hard to make RubyGems understand that
>
> > 1.0.0rc10 > 1.0.0rc1
>
> > and
>
> > 1.0.0 > 1.0.0rc1
>
> > That's really all that's needed.
>
> > And ~> should just not consider any version with lettering at the end.
>
> > T.
>
> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the user
> system.
No. I think people use ~> when they expect very tight and rational
versioning. So ~> means production code only, and rc30 would not fit
the bill. That's what I meant by "not consider".
If one wanted to accept rc versions, then use > or >= instead.
> Riiight. That also bring things related to cleanup of these gems...
> what to do if you're not considering these cases in full spectrum?
Seems to me one should also be able to tell the gem command "consider
production releases only".
T.
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
