Dave:
> Personally, I'd prefer 
> an understanding that RAA modules should always be compatible with
> prior versions across minor revision upgrades.

Being able to specify needed at least Foo 1.6 is nice for forward
declarations. But it's not enough for production environment. I could
imagine we're running two programs which both use Foo. The older one was
made for 1.3 and runs nicely with up to 1.5 and the newer is designed
specifically for the newest Foo 1.6. Newest release changed (corrected) the
behaviour of one little sweet 'feature' (someone called this side-effect
brutally as a bug).

The problem, however, arises when the older program has been programmed to
rely on the existence of this side effect. The small change in Foo can't be
thought to be major, since the fix is very simple and easy, so one could
easily upgrade from 1.5 to 1.6. And besides, you shouldn't be relying on
side effects anyway. The problem is that while the fix is easy to do for any
code -- including the older one -- making it for production code might not
be. Imagine the old monster is a monolithic beast with some hundreds of
thousands of code line with probably thousands of required changed to be
*tested*.

So, while resisting major rewrite pressure for few more years the old
monster has to be running lively. As does the new baby too. And these should
be on same machine, using different versions of the library (maybe that lib
is even an extension). And I hope Ruby will be up to that.

Actually Erlang goes one step further. The interpreter has the ability to
use two different versions of the same library at the same. But I think the
feature allows one only to update the currently used lib, not really have
two programs running and using different versions of the lib, so from the
programs point of view they are just using one version at the time; the
newest possible.

So it could be considered to be a requirement to have multiple versions of
same lib around for different interpreter instances, and it would be nice to
be able to use multiple instances of the libraries inside one interpreter
simultaneously. 

While I consider the latter be quite marginal case it might allow one to
write easier programs which migrate data from older format to the newer one
like 

require "Foo" 1.4 as Foo_old
require "Foo" 1.5 as Foo_new

foo_old = Foo_old::Foo.new.load("old_data_format")
foo_new = Foo_new::Foo.new

# assuming the data model hasn't changed at all (or very little)
foo_new.copy_contents_from(foo_old) # just as from any instance of
Foo_new::Foo
foo_new.save("new_data_format")

Robert:
> > * If Ruby cannot find a compatible extension locally it 
> >   would go to RAA
> >   (Ruby Application Archive) or other CPAN-like repository and query
> >   it for the latest compatible version. It would then download and
> >   install the package.

Dave:
> On most people's Unix boxes, this would require that the applications
> should be run as root, which is not really an option. Even when this
> isn't the case, this could lead to all sorts of issues.

This shouldn't be the case. If it is, I'd like to see a change. 

I'd say one should be able to specify config for ruby where one entry could
be 'allow Ruby to auto-install from CRAN' and another 'try to install to
user's home directory structure if not run as root'. And letting it to be
user's responsibility to have both directory structures at the RUBY_LIB.
(Maybe installation could create ruby.env-file which one could 'source
~/.ruby.env' at appropriate place?)

	- Aleksi