I think before RVM became so popular it was rather common not to use differ=
ent prefixes, but to simply append a suffix (like ruby18 and ruby19) to all=
 the executables. There is a simple configure switch for that and this was =
also the structure used by the Debian Ruby packages iirc. Also, you do not =
have to change any env vars just to switch the Ruby version.

Konstantin

On Aug 10, 2011, at 21:13 , V=EDt Ondruch wrote:

> Dne 10.8.2011 14:40, Michael Klishin napsal(a):
>> 2011/8/10 V=EDt Ondruch <v.ondruch / gmail.com>
>> And what is the reason in real life to have two versions of Ruby on your=
 computer, since the first think which will conflict is the Ruby executable=
, the second are manual pages, etc ...
>>=20
>> To work on different applications, both old (and thus using 1.8.7) and n=
ew (typically started on 1.9.2 these days). To make sure your libraries wor=
k on multiple Ruby versions. To provide multiple Ruby versions in case of h=
oster/cloud providers. To let people run CI against multiple Ruby versions =
like travis-ci.org.
>>=20
>> Conflicts with Ruby executable are solved by version prefixes or tools l=
ike RVM. RVM solves plenty of other issues like isolated gem sets.
>>=20
>> Every person I know who has released at least one gem has more than one =
Ruby installed and often uses RVM for that.
>> --=20
>> MK
>>=20
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>=20
>=20
> But for every case you have mentioned, I would prefer to install into loc=
ation with different prefix, e.g. /opt/ruby18 and /opt/ruby19 so the versio=
n numbers are useless. So again, I am wondering if somebody mixes Ruby 1.8 =
and Ruby 1.9 into one folder in reality, not if that is possible in theory.
>=20
>=20
> And exactly tools like RVM leads me to questioning the rationale behind v=
ersion numbers in paths.
>=20
>=20
> Vit