On Sat, Jun 28, 2014 at 2:45 AM, Nick Wellnhofer <[email protected]> wrote: > On Jun 24, 2014, at 06:30 , Marvin Humphrey <[email protected]> wrote: > >> On Mon, Jun 23, 2014 at 10:03 AM, Peter Karman <[email protected]> wrote: >>> I think it's been awhile since I asked this last and there's been some >>> repo churn. >>> >>> What's stopping us from a 0.4 release? >> >> We've been blocking for a while on severing Clownfish from Lucy, but >> that's now finished, hooray! The big remaining question mark is >> maturity of the Clownfish API. If we punt on the issue and hide the >> Clownfish API, so that the Clownfish distro is essentially an opaque >> prereq for Lucy, the amount of work left to make a Lucy 0.4.0 release >> is reasonably small. >> >> Releasing an opaque Clownfish alongside Lucy will give us a chance to >> work out bugs which have been introduced during the refactoring. Then >> we can reveal great new features like the C API on subsequent releases >> which enjoy greater stability. > > Yes, I think Clownfish is ready for release.
There are four issues that I'd consider particularly important to work through before the Clownfish API is exposed, because they have global impact and would be disruptive to change on subsequent releases. * Replace `::` with `.` as a namespacing separator. * Prefer fully qualified namespacing parcels, e.g. 'org.apache.lucy'. * Prevent subclassing of most Clownfish core classes. * Review names of core classes: VTable -> Class, VArray -> Array. There are also a number of API issues at the level of individual classes which I think need review. However they either have more localized impact (individual method signatures), are less consequential or are less disruptive to change (Num, Err APIs). > (In retrospect, I think the Clownfish compiler > should have been written as a Clownfish project itself using a simple > bootstrapping version in Perl. This would save us some headaches in the long > run.) Clownfish's design is intended to facilitate such migrations. We can transition individual modules within the CFC compiler from C to Clownfish-flavored C one-by-one, just as we transitioned individual modules within Lucy one-by-one from XS-flavored C to Clownfish-flavored C. The compiler and all its tests will still work during the entire incremental process. > Then we have to adjust the documentation of the Clownfish header file > language for some of the recent renaming. The documentation of the C API for > Clownfish and Lucy needs work, too, but that’s something we can postpone. > > I think the best way to proceed is to put a Clownfish dev release on CPAN as > soon as possible. This gives us a lot of testers for free and it’s a great > way to review the documentation. This isn't what I had in mind -- I was proposing to hide most or all of that documentation, allowing us to air out the implementation before dealing with publicizing the API. I still think that's a better plan... but you've contributed so much, Nick, that I'd rather find a way to bend and bring us together. If cloaking isn't an option, an you give me a month to deal with those four issues I listed above? I will deprioritize everything else to work on them, including the release process reform initiative I've been pushing on legal-discuss@apache, the return of the Lucy Book Club, and some internal $work projects. It turns out that in the end, getting Clownfish right is what I care about most. Marvin Humphrey
