On Mon, 10 Jan 2005, Greg A. Woods wrote:

> > That's unrelated.  I'm talking within-major-version backwards compatibility
> > here (5.8.5 to 5.8.6, for example, where there is usually not a libperl ABI
> > change), not compatibility from 5.6 to 5.8.
>
> There will always eventually be a new major version to consider
  [...]
> Building this capability into the infrastructure for handling perl now,
> just as it's done with ruby, and should be done with python etc. too,
> would ensure that it becomes second nature and works well for that
> inevitability.

Sure, although the distance between them is pretty great.  Any theoretical
major version update to Perl 5.x may require this kind of division, but it's
looking pretty unlikely that Perl 5 will have any more major releases.

Now, Perl 6 is such a major change that it will require the type of
separation you suggest -- but likely not in the way you are currently
envisioning, as it is itself radically different from Perl 5.  So doing the
work right now for zero present gain may actually be a gross waste of time.

However, that was not the point of this particular thread.

> The fact that there are both language compatability and loadable module
> ABI compatability issue to worry about only seems to make it more
> important.

To restate myself from the other thread:

If there's only one version of perl[5] in pkgsrc, what's the difference?

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>