On Thu, Sep 16, 2010 at 11:44 AM, Marcus Rueckert <darix / opensu.se> wrote:
> On 2010-09-16 03:36:56 +0900, James Cox wrote:
>>  ¨Â äïî§âåìéåöôèéóóõéó áó çòáöáó ùïóõççåóô® ôèåòå§îï
>> 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.
>
>  ¨Âáòéø
>
> --
> openSUSE - SUSE Linux is my linux
> openSUSE is good for you
> www.opensuse.org
>
>

- you could just reference a certain number of gems from ruby config
files, and the desired/tested version. this way the author can
continue work independently of ruby-core, and ruby core can also
approve or certify a certain version for a next release.  There's no
reason to impose extra versioning IMHO.
- you could also give the choice to the developer whether or not they
want to install the corresponding gems: an option, the default being
'do install', but an advanced user being able to just install minimal
ruby and mix and match afterwards.

I hope I'm making sense,

Elise