On 8/13/04 10:12 AM, "Austin Ziegler" <halostatue / gmail.com> wrote:

> RPA's concept of cleanly interworking versions as a "release" seems
> completely incompatible with RubyGems total version anarchy. At the
> same time, the ability to install any version at any time --
> accepting the risks involved -- is an advantage of RubyGems at the
> moment. I like the ability to say "use release version 5" and get
> known versions of libraries that work together nicely (at least in
> theory), but also want the ability to say "use release version 5,
> but use version 7 of this package".


So, with gems you can have multiple versions of a single library installed
at the same time...cool, but maybe not commonly used (on the surface).  If
you think in terms of "sets" of versioned gems however, you arrive at the
same 'library' idea, but the 'library' can co-exist with another 'library'.
In other words, if you said I want to use library 'stable' and it mods the
load path with all of the listed gems of a specified version you then
'require' just like to did before, and you get a set of gems that have been
QA'd to work together...there ya go.  Oh, and with the same 'set' you could
install it (all) or nothing...so you are guaranteed a base to work from (as
far as use goes).

Simple exammple:

Set 1:
jabber4r-0-7-0
ikko-0-1-0

Set 2:
jabber4r-0-8-0
ikko-0-2-0

With gems you could have one script request Set 1 and another script request
Set 2 on the same machine, at the same time, without a problem.  Who defines
the 'sets' is another issue.  We don't do the 'set' thing right now, but
really, that is a minor addition.

We don't have version anarchy, we have library author autonomy.

-rich