Re^2: How can I (safely) use packages of the same name but different versions?

I don't know anything about xevian's situation, but one place where I can see something kind of like this come up is when there are backward compatibility problems. For example, let's say DBD::XYZ version 1 only supports XYZ database version 1, whereas DBD::XYZ version 2 only supports XYZ database version 2. If your code, for whatever reason, might have to connect to instances of different versions of XYZ within a single program, you're going to have a problem.

Comment on Re^2: How can I (safely) use packages of the same name but different versions? Select or Download Code

Replies are listed 'Best First'.
Re^3: How can I (safely) use packages of the same name but different versions? by samtregar (Abbot) on Mar 12, 2008 at 16:08 UTC
I've heard rumors that Perl 6 will solve this problem. Personally I don't think it's going to be all that helpful. New versions are released for a reason - leaving old code using old versions of their dependencies is only going to get you so far. Your example is a good one - if XYZ v1 and v2 are both being used to access the same physical database then you've likely got a problem that Perl alone supporting multiple version loading can't solve. I haven't had a chance to try it yet, but I thought Erlang's facility for running multiple versions of code long enough to do a seemless cut-over sounded smart. Since everything in Erlang is a networked server the system starts up the new version and starts sending all new requests to it. Once the old version is done handling any lingering requests it gets shutdown. -sam	[reply]
Re^4: How can I (safely) use packages of the same name but different versions? by Errto (Vicar) on Mar 12, 2008 at 17:58 UTC
The database thing happens to be a non-hypothetical question for me. I'm not giving details because my actual situation involves Java, not Perl, but the concept is the same.	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks