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.
Riiight. That also bring things related to cleanup of these gems...
what to do if you're not considering these cases in full spectrum?
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
