On Mon, Dec 14, 2015 at 3:37 AM, Nick Wellnhofer <[email protected]> wrote:
> Lucifers,
>
> I'm mostly done with the things I wanted to get in the 0.5 release:
>
> - Review the Clownfish runtime API.
> - Document the C API.
> - Document the Clownfish header file language.
> - Document the cfc compiler for C projects.
>
> Other things that should be done:
>
> - Clownfish tutorial, see CLOWNFISH-43:
> https://issues.apache.org/jira/browse/CLOWNFISH-43
> - Review and add missing DocuComments.
> - Add a Clownfish page and the HTML documentation to lucy.apache.org.
> - Check for incompatible versions of Perl modules (see below).
>
> Things that would be nice:
>
> - Document the CFC compiler for Perl projects.
> - Utility to create boilerplate code for a new Clownfish project.
>
> The other big feature in 0.5 are the Go bindings. Marvin, what's the status
> here? Do you think it's realistic to aim for a release early next year?
>
> Any other things I'm missing?
I'm content with your list. The main thing I wanted to get in was the Go
bindings. If all goes according to plan, the next feature I work on will be
Python bindings.
> Regarding the Perl modules: When we make new Clownfish and Lucy releases
> that are incompatible with the 0.4 branch, we'll run into a serious problem.
> If a Lucy 0.4 user installs Clownfish 0.5, Lucy will stop working in a
> rather unpredictable way. I guess that Lucy simply won't load because of
> symbols removed from Clownfish.so, so at least there's no danger of data
> corruption. The error message will be rather cryptic, though.
>
> Perl doesn't allow to install multiple versions of a module, so an obvious
> solution is to use a separate namespace for different major versions like
> Lucy::0.4, Clownfish::0.5.
Versioning is a hard problem. As much as I would like to make progress on it,
with multiple hosts to support, I've come to think that Clownfish shouldn't be
too ambitious about providing simultaneous support for multiple versions.
> We could also keep using the same namespace and die with a meaningful error
> message if an incompatible version of a prerequisite is detected. I envision
> something like the "compatibility version" in Darwin dynamic libraries. The
> compatibility version is the lowest version a parcel is compatible with,
> typically the first release of a major version. For example, Clownfish.cfp
> would contain:
>
> version: "v0.5.2",
> compatibilityVersion: "v0.5.0",
How about instead endorsing SemVer for Clownfish-powered libraries? That way,
compatibility is encoded in version numbers.
http://semver.org/
For Clownfish runtime releases prior to 1.0, we can hack something in which
provides the effect of compatibilityVersion without making it a public
feature.
> Then any parcel requiring Clownfish can check whether `compatibilityVersion`
> is lower to or equal than the required version (in addition to the check
> whether `version` is higher than or equal to the required version). In other
> words, a prerequisite can only be used for parcels requiring a version
> between `compatibilityVersion` and `version` inclusive. The Perl
> implementation is a bit tricky because the check must be done before
> Clownfish.xs is bootstrapped.
We could do something like install a pure-Perl .pm file which contains the
compatibility version, e.g. `lib/Clownfish/CFCompat.pm`,
`lib/Lucy/CFCompat.pm`.
Maybe we can figure out how to have autogenerated bootstrapping code look for
that file, though that's non-trivial as you point out. But in the short term
we can just hack something into a BEGIN block at the top of Lucy.pm.
> Unfortunately, we'd need this feature to be present in the Lucy 0.4 branch
> to make this work. Maybe we should make a new 0.4 release first?
+1, sane error messages are important.
Marvin Humphrey
