On 2010-09-16 03:36:56 +0900, James Cox wrote:
>  I don't believe the issue is as grave as you suggest. there's no
> reason that stdlib needs to be at the same release version as ruby; it
> just needs to be clear what the cutoff points are. However, if i am
> wrong, the fix is simple: specify to each stdlib maintainer that they
> are not at liberty to update release versions outside of ruby, other
> than to specify patch level releases until the newer ruby is made.

ok I thought a bit more about your idea ... and it is not going to work.
lets say you force a library to a versioning scheme of 1.9.2.z. where
they are only allowed to update the z part.

now we currently have
various 1.8.x
1.9.1
1.9.2

do you want to force library authors to release a gem for each active
branch to keep your versioning pattern?

should we really end up with something like
rubygems-1.8.7.1
rubygems-1.9.1.2
rubygems-1.9.2.2

(just using rubygems as an example)

the unified versioning idea doesnt make sense at all. and it doesnt even
touch alternative ruby interpreter.

    darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org