From: James Tucker <jftucker@...>
Date: 2010-09-16T23:45:57+09:00
Subject: [ruby-core:32432] Re: Can we convert the standard library to gems?


On 16 Sep 2010, at 06:54, elise huard wrote:
> - 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.

This is not true. Users will do `gem update` and shoot themselves in the foot. As one of the people who spends a lot of time on user support, I would be really really upset to see this kind of dangerous action. As Marcus points out, there are even issues with this as an approach for versioning between different rubies too. We can protect against a /portion/ of this with the required_ruby_version flag in the gemspec, but I at present I /believe/ that's only a minimum version marker. For this purpose it will need '=' or at least '~>' semantics or options to be sane.

> - 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 suggested this originally. Add them to an optional distribution set in a directory as actual gem files. When building the "big release" you include these gem files in the same way as you include the parser builds. In small releases or minimal packages, these could be excluded. If users don't want them during the install, they can either remove them from the big release package, or add them to the small release package. This simple approach also allows users to /add/ to the packages for their own needs.