On 22/12/2015 01:31, Marvin Humphrey wrote:
Yeah, I know what you mean!  The complexity arises, though, when there are
multiple consumer libraries which require conflicting versions of a dependency
AND which expect to exchange types defined by the dependency.  What if the
types defined by different versions of the dependency are not compatible?

In this case, direct interoperability is simply impossible. But this is a problem that affects any language environment that allows to use multiple versions of a library in a single program.

Nevertheless, it should be possible to support two isolated libraries that require different versions of a prerequisite like the Clownfish runtime. For example:

    Lucy 1.0     requires Clownfish 1.0
    ProjectX 2.0 requires Clownfish 2.0

Even if Lucy 1.0 and ProjectX 2.0 don't exchange any Clownfish objects, the current implementation doesn't allow to run both libraries under Perl. This is a serious limitation that should be addressed at some point.

I'm not sure that's a solveable problem -- and thus making it possible for
multiple versions of a library to co-exist within a single process seems to
have limited value.  At most, I think we can contemplate dynamic loading of a
custom version on demand at runtime.  But for hosts where that's not normally
supported, like Perl, I'm reluctant to go there.

Well, Perl supports this more or less by embedding a version number in every class name. Of course, it's cumbersome to write and maintain something like

    my $indexer = Lucy::v0.5::Index::Indexer->new; # or
    my $indexer = Lucy::Index::Indexer::v0.5->new;

But I don't think it's too bad.

The phrase "arbitrary version numbering schemes" scares me pretty bad...
However, I think you only mean compatibility with an arbitrary previous
version and not arbitrary ordering, arbitrary version number format, etc --
i.e. only what compatibilityVersion would provide.

Yes, I only meant that.

I can live with compatibilityVersion.  I think we should still endorse SemVer,
though -- even if we extend it with compatibilityVersion.

I just realized that Darwin's "compatibility version" is a bit different than what we need for Perl. It's used for minor version compatibility, but we need something to ensure major version compatibility (something equivalent to "soname" for ELF or "install name" for Darwin libraries). So let's use a different name.

Nick

Reply via email to