From: elise huard Date: 2010-09-16T18:54:05+09:00 Subject: [ruby-core:32423] Re: Can we convert the standard library to gems? On Thu, Sep 16, 2010 at 11:44 AM, Marcus Rueckert wrote: > 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 > > - 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