From: Chris Morris <chrismo@...>
Date: 2002-09-10T07:18:20+09:00
Subject: Re: Multiple .rb versions support

> In general, I don't like seeing versioning managed in the filesystem,
> because it adds alot of clutter.
>
> What is the problem that this functionality would solve?
>
> Please humor me, I've just never had a problem with Ruby that begged
> for integrated versioning.

For example, I have an XmlSerialization lib that currently depends on REXML,
and I've only tested it with version 1.2.5. Until I get time to verify it
with later versions (I know, 1.2.5 has been gone for quite some time,
there's internet time and then there's open source project volunteer time)
If there was a common versioning scheme that REXML used, I could build that
into my xmlserial lib to require an older version. Or ... a better example,
if I knew there was a bug in 1.2.4 that caused my lib to fail, then I could
require 1.2.5 or better be used to make sure my stuff worked.

Now ... REXML has its own VERSION constant in there I can check -- so my
approach is still doable, it just might be nice to have a standard way of
handling dependencies.

Now ... let's say I have need to run the latest REXML for another app I'm
writing, but need to use the latest version. It'd be nice to be able to have
both 1.2.5 installed to support my existing applications, which I don't have
time to upgrade, plus the latest version for the new app.

.Net has a way of supporting multiple versions of assemblies (.dlls,
essentially) to avoid DLL-Hell, a common Windows problem with multiple
programs overwriting shared .dlls (like msvcrt.dll) in the system directory.

Chris