You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2014/06/23 19:03:50 UTC
[lucy-dev] 0.4 release?
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?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Aug 18, 2014 at 5:55 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> * The valgrind test targets have been modernized to use a more flexible
> suppressions format and are now more reliable and less fussy about
> compilation options and Perl versions. I'll give it another pass before
> submitting the RC but they should be passing.
I found a memory leak in RC1, which I will now discard. After
committing a fix, I'll roll RC2.
Marvin Humphrey
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On Aug 19, 2014, at 19:52 , Marvin Humphrey <ma...@rectangular.com> wrote:
> Clownfish is likely to remain in significant flux at least until we've
> implemented bindings for more languages. Here are some of the upcoming
> challenges which will likely require modifications to the Clownfish core:
>
> * Tracing GC (Ruby, Go)
I’ve also been thinking about this. It should be feasible if we keep track of all Clownfish objects that were passed to the host language.
> * Non-UTF-8 host string type (Python)
A simple approach would be to reencode every string that is passed from the host language and back. But for a more performant solution, Clownfish needs support for multiple string encodings.
> * Limited access to GC internals hampers host subclassing (Go)
I don’t know anything about how Go interfaces with C, but I can imagine that the lack of virtual methods in Go poses an interesting problem.
> This is super fun stuff to work on. :)
I hope you didn’t mean that ironically. It definitely sounds like fun stuff to me. :)
> Having Lucy as a real-world example is invaluable during this period and I
> think releases will be coordinated for a while yet.
Yes, but now that Clownfish is cleanly separated, it should be much easier to start supporting new host languages without having to care about Lucy at first.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Aug 19, 2014 at 5:28 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> I could imagine that the release schedules of Lucy and Clownfish will
> diverge at some point. Maybe we should also try to keep the Lucy master
> branch compatible with an official Clownfish release. Then Lucy would only
> be updated for Clownfish changes once a new version of Clownfish is
> released. This would essentially force us to release Lucy and Clownfish
> separately.
In the long term, divergence is inevitable.
> On the other hand, it might be useful to test whether changes to Clownfish
> work with Lucy as soon as possible.
Clownfish is likely to remain in significant flux at least until we've
implemented bindings for more languages. Here are some of the upcoming
challenges which will likely require modifications to the Clownfish core:
* Tracing GC (Ruby, Go)
* Ordering requirements for optional parameters (Python)
* Non-UTF-8 host string type (Python)
* Limited access to GC internals hampers host subclassing (Go)
* Mapping parcel/class names to host names and constructs (all)
This is super fun stuff to work on. :)
Having Lucy as a real-world example is invaluable during this period and I
think releases will be coordinated for a while yet.
Marvin Humphrey
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On 19/08/2014 02:55, Marvin Humphrey wrote:
> Since Clownfish and Lucy will henceforth be separate products, I plan to run
> separate votes for this first independent release of Clownfish. In the future
> we might run a combined vote for the sake of convenience.
I could imagine that the release schedules of Lucy and Clownfish will diverge
at some point. Maybe we should also try to keep the Lucy master branch
compatible with an official Clownfish release. Then Lucy would only be updated
for Clownfish changes once a new version of Clownfish is released. This would
essentially force us to release Lucy and Clownfish separately.
On the other hand, it might be useful to test whether changes to Clownfish
work with Lucy as soon as possible.
> Reviewing the checklist at <http://wiki.apache.org/lucy/ReleasePrep>:
>
> * The RAT buildbot is currently passing for Lucy. We don't have a RAT
> buildbot for Clownfish AFAIK so I ran RAT locally and the output looked
> OK.
> * The issue tracker is clean for 0.4.0.
> * The Lucy CHANGES file has been brought up to date and the Clownfish
> CHANGES file has been inaugurated.
> * LICENSE and NOTICE look correct for both Lucy and Clownfish.
> * As of a week or two ago, Lucy and Clownfish built and passed tests on a
> variety of Windows configurations, plus Linux, FreeBSD (our buildbot) and
> OS X. It might be nice to check NetBSD and Solaris.
> * The valgrind test targets have been modernized to use a more flexible
> suppressions format and are now more reliable and less fussy about
> compilation options and Perl versions. I'll give it another pass before
> submitting the RC but they should be passing.
>
> In addition, the update_version scripts have been been adapted for the changes
> since 0.3.x and I've checked the product of the CPAN dist building process.
> Every module listed in 'provides' has the correct version number (though to be
> honest the list of classes is not exhaustive) so we should get a clean index
> on CPAN.
Looks good.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 8/18/14 7:55 PM:
> Greets,
>
> I think we're pretty much done prepping 0.4.0 and it's time to call a release
> vote as soon as the prep_0.4.0 branches are merged to master.
sweet.
A big thanks to you and Nick for pulling all this together. I look forward to
Life With Apache Clownfish and what comes next.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
Greets,
I think we're pretty much done prepping 0.4.0 and it's time to call a release
vote as soon as the prep_0.4.0 branches are merged to master.
Since Clownfish and Lucy will henceforth be separate products, I plan to run
separate votes for this first independent release of Clownfish. In the future
we might run a combined vote for the sake of convenience.
Reviewing the checklist at <http://wiki.apache.org/lucy/ReleasePrep>:
* The RAT buildbot is currently passing for Lucy. We don't have a RAT
buildbot for Clownfish AFAIK so I ran RAT locally and the output looked
OK.
* The issue tracker is clean for 0.4.0.
* The Lucy CHANGES file has been brought up to date and the Clownfish
CHANGES file has been inaugurated.
* LICENSE and NOTICE look correct for both Lucy and Clownfish.
* As of a week or two ago, Lucy and Clownfish built and passed tests on a
variety of Windows configurations, plus Linux, FreeBSD (our buildbot) and
OS X. It might be nice to check NetBSD and Solaris.
* The valgrind test targets have been modernized to use a more flexible
suppressions format and are now more reliable and less fussy about
compilation options and Perl versions. I'll give it another pass before
submitting the RC but they should be passing.
In addition, the update_version scripts have been been adapted for the changes
since 0.3.x and I've checked the product of the CPAN dist building process.
Every module listed in 'provides' has the correct version number (though to be
honest the list of classes is not exhaustive) so we should get a clean index
on CPAN.
Marvin Humphrey
Re: [lucy-dev] 0.4 release?
Posted by Peter Karman <pe...@peknet.com>.
On 6/23/14 11:30 PM, Marvin Humphrey wrote:
> On Mon, Jun 23, 2014 at 10:03 AM, Peter Karman <pe...@peknet.com> 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.
>
I like the idea of a opaque Clownfish. Gives us time to flesh out a
public API based on actual use.
Is this our list of remaining 0.4 issues?
https://issues.apache.org/jira/browse/LUCY/fixforversion/12319858
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On 01/07/2014 05:07, Marvin Humphrey wrote:
> On Mon, Jun 30, 2014 at 7:21 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> You had voiced support for going from VTable to Class:
>
> http://s.apache.org/yNW
>
> By the way, I'm really in favor of renaming Clownfish::VTable to
> Clownfish::Class.
>
> So if you get to that before I do, great. Otherwise, I understand that I'm
> the one blocking and it's my responsibility to make stuff happen.
Yes, I'd like to work on that.
> Possible concerns:
>
> * Some host languages provide a getClass() method, which we'll want to avoid
> clashing with. So when we rename Obj#Get_VTable(), we'll need to name it
> something like Get_CFClass().
I'd prefer to add a host method alias in this case.
> * We can't name a struct member `class`[1]. We might go with either
> `cfclass` or `klass` (both of which I'd prefer over `cls` or `clazz`).
I don't have a strong preference but we've been using "klass" in CFC anyway so
let's stick with that.
> * My personal preference would be to have no `nickname` for Class, rather
> than the unpronounceable `Cls`: Class_Get_Name(), Class_Make_Obj(), etc.
+1.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Logan Bell <lo...@gmail.com>.
+1
I couldn't have said it better.
On Tue, Jul 1, 2014 at 6:59 AM, Peter Karman <pe...@peknet.com> wrote:
> Marvin Humphrey wrote on 6/30/14 11:07 PM:
> > On Mon, Jun 30, 2014 at 7:21 AM, Nick Wellnhofer <we...@aevum.de>
> wrote:
> >> I don't see much use in releasing Lucy 0.4 with an opaque version of
> >> Clownfish. There aren't any major new features in the 0.4 release so
> Lucy
> >> users can stick with 0.3 as well. I'm more concerned with not delaying
> the
> >> Clownfish release any longer.
> >
> > It doesn't bother me in the slightest to make a release with no
> significant
> > visible features.
> >
> > In fact, I suggest that we start releasing on a fixed cadence at
> one-month
> > intervals as we roll out Clownfish.
>
> +1
>
> I consider it part of the release-early/often philosophy to push releases
> that
> may only have changes in documentation or internal refactoring. It gives
> the
> testers something to chew on and helps keep development aligned with actual
> users. Also (and often under-emphasized) the psychological effect of
> seeing "and
> yet another release of Whatever" reflects that the project is alive and
> well and
> Doing Stuff, even if that stuff is invisible to end-users.
>
>
> --
> Peter Karman . http://peknet.com/ . peter@peknet.com
>
Re: [lucy-dev] 0.4 release?
Posted by Logan Bell <lo...@gmail.com>.
I could be wrong, but I thought there has been been work done on the Lucy
side for the C bindings. Or is this strictly only related to Clownfish?
On Tue, Jul 1, 2014 at 9:47 AM, Peter Karman <pe...@peknet.com> wrote:
> Nick Wellnhofer wrote on 7/1/14 11:29 AM:
> > On 01/07/2014 15:59, Peter Karman wrote:
> >> I consider it part of the release-early/often philosophy to push
> releases that
> >> may only have changes in documentation or internal refactoring. It
> gives the
> >> testers something to chew on and helps keep development aligned with
> actual
> >> users. Also (and often under-emphasized) the psychological effect of
> seeing "and
> >> yet another release of Whatever" reflects that the project is alive and
> well and
> >> Doing Stuff, even if that stuff is invisible to end-users.
> >
> > It really depends on the project. IMO, a monthly release cycle is total
> overkill
> > for Lucy. There would be quite a few months where simply nothing
> happens. We
> > also have very few active developers. Personally, I prefer to spend my
> time on
> > other things than cutting a release that doesn't add real value to users
> or
> > developers. But if anyone wants to release 0.4 now for whatever reasons,
> I
> > wouldn't object. The master branch has always been stable.
> >
> > I only want to make sure that when we make a public release of
> Clownfish, it
> > should be somewhat usable and properly documented. Failing this, I agree
> that we
> > should bundle Clownfish with Lucy and hide any of its APIs.
> >
>
> +1
>
> It's because we have so few active developers (you and Marvin for this
> Clownfish
> release) that I agree with keeping Clownfish private till you both feel it
> is
> mature (documented, tested, etc) enough to make public.
>
>
> --
> Peter Karman . http://peknet.com/ . peter@peknet.com
>
Re: [lucy-dev] 0.4 release?
Posted by Peter Karman <pe...@peknet.com>.
Nick Wellnhofer wrote on 7/1/14 11:29 AM:
> On 01/07/2014 15:59, Peter Karman wrote:
>> I consider it part of the release-early/often philosophy to push releases that
>> may only have changes in documentation or internal refactoring. It gives the
>> testers something to chew on and helps keep development aligned with actual
>> users. Also (and often under-emphasized) the psychological effect of seeing "and
>> yet another release of Whatever" reflects that the project is alive and well and
>> Doing Stuff, even if that stuff is invisible to end-users.
>
> It really depends on the project. IMO, a monthly release cycle is total overkill
> for Lucy. There would be quite a few months where simply nothing happens. We
> also have very few active developers. Personally, I prefer to spend my time on
> other things than cutting a release that doesn't add real value to users or
> developers. But if anyone wants to release 0.4 now for whatever reasons, I
> wouldn't object. The master branch has always been stable.
>
> I only want to make sure that when we make a public release of Clownfish, it
> should be somewhat usable and properly documented. Failing this, I agree that we
> should bundle Clownfish with Lucy and hide any of its APIs.
>
+1
It's because we have so few active developers (you and Marvin for this Clownfish
release) that I agree with keeping Clownfish private till you both feel it is
mature (documented, tested, etc) enough to make public.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On 01/07/2014 15:59, Peter Karman wrote:
> I consider it part of the release-early/often philosophy to push releases that
> may only have changes in documentation or internal refactoring. It gives the
> testers something to chew on and helps keep development aligned with actual
> users. Also (and often under-emphasized) the psychological effect of seeing "and
> yet another release of Whatever" reflects that the project is alive and well and
> Doing Stuff, even if that stuff is invisible to end-users.
It really depends on the project. IMO, a monthly release cycle is total
overkill for Lucy. There would be quite a few months where simply nothing
happens. We also have very few active developers. Personally, I prefer to
spend my time on other things than cutting a release that doesn't add real
value to users or developers. But if anyone wants to release 0.4 now for
whatever reasons, I wouldn't object. The master branch has always been stable.
I only want to make sure that when we make a public release of Clownfish, it
should be somewhat usable and properly documented. Failing this, I agree that
we should bundle Clownfish with Lucy and hide any of its APIs.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 6/30/14 11:07 PM:
> On Mon, Jun 30, 2014 at 7:21 AM, Nick Wellnhofer <we...@aevum.de> wrote:
>> I don't see much use in releasing Lucy 0.4 with an opaque version of
>> Clownfish. There aren't any major new features in the 0.4 release so Lucy
>> users can stick with 0.3 as well. I'm more concerned with not delaying the
>> Clownfish release any longer.
>
> It doesn't bother me in the slightest to make a release with no significant
> visible features.
>
> In fact, I suggest that we start releasing on a fixed cadence at one-month
> intervals as we roll out Clownfish.
+1
I consider it part of the release-early/often philosophy to push releases that
may only have changes in documentation or internal refactoring. It gives the
testers something to chew on and helps keep development aligned with actual
users. Also (and often under-emphasized) the psychological effect of seeing "and
yet another release of Whatever" reflects that the project is alive and well and
Doing Stuff, even if that stuff is invisible to end-users.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 30, 2014 at 7:21 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> I don't see much use in releasing Lucy 0.4 with an opaque version of
> Clownfish. There aren't any major new features in the 0.4 release so Lucy
> users can stick with 0.3 as well. I'm more concerned with not delaying the
> Clownfish release any longer.
It doesn't bother me in the slightest to make a release with no significant
visible features.
In fact, I suggest that we start releasing on a fixed cadence at one-month
intervals as we roll out Clownfish.
> Regarding the four issues you mentioned:
>
>> * Replace `::` with `.` as a namespacing separator.
>> * Prevent subclassing of most Clownfish core classes.
>> * Review names of core classes: VTable -> Class, VArray -> Array.
>
> These should be more or less trivial.
They're all more tricky than they appear at first glance, though.
I figure the first task I'll take up will be be making more Clownfish core
classes final.
> If you think it's important to get this sorted before we release Clownfish,
> then, by all means, take your time. I'd be happy to help with any tasks that
> can be parallelized.
You had voiced support for going from VTable to Class:
http://s.apache.org/yNW
By the way, I'm really in favor of renaming Clownfish::VTable to
Clownfish::Class.
So if you get to that before I do, great. Otherwise, I understand that I'm
the one blocking and it's my responsibility to make stuff happen.
Possible concerns:
* Some host languages provide a getClass() method, which we'll want to avoid
clashing with. So when we rename Obj#Get_VTable(), we'll need to name it
something like Get_CFClass().
* We can't name a struct member `class`[1]. We might go with either
`cfclass` or `klass` (both of which I'd prefer over `cls` or `clazz`).
* My personal preference would be to have no `nickname` for Class, rather
than the unpronounceable `Cls`: Class_Get_Name(), Class_Make_Obj(), etc.
Marvin Humphrey
[1] http://stackoverflow.com/questions/12533326/clang-c-compiler-class-keyword-reserved
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On 29/06/2014 20:51, Marvin Humphrey wrote:
> 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.
I don't see much use in releasing Lucy 0.4 with an opaque version of
Clownfish. There aren't any major new features in the 0.4 release so Lucy
users can stick with 0.3 as well. I'm more concerned with not delaying the
Clownfish release any longer.
Regarding the four issues you mentioned:
> * Replace `::` with `.` as a namespacing separator.
> * Prevent subclassing of most Clownfish core classes.
> * Review names of core classes: VTable -> Class, VArray -> Array.
These should be more or less trivial.
> * Prefer fully qualified namespacing parcels, e.g. 'org.apache.lucy'.
This is more involved. For the record, here are some related threads:
http://s.apache.org/6wE
http://s.apache.org/VUJ
If you think it's important to get this sorted before we release Clownfish,
then, by all means, take your time. I'd be happy to help with any tasks that
can be parallelized.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sat, Jun 28, 2014 at 2:45 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> On Jun 24, 2014, at 06:30 , Marvin Humphrey <ma...@rectangular.com> wrote:
>
>> On Mon, Jun 23, 2014 at 10:03 AM, Peter Karman <pe...@peknet.com> 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
Re: [lucy-dev] 0.4 release?
Posted by Nick Wellnhofer <we...@aevum.de>.
On Jun 24, 2014, at 06:30 , Marvin Humphrey <ma...@rectangular.com> wrote:
> On Mon, Jun 23, 2014 at 10:03 AM, Peter Karman <pe...@peknet.com> 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. The only thing that still needs work is the documentation, especially for the Clownfish compiler. I updated the cfc-pod branch which generates some minimal documentation for the CFC Perl bindings from the C header files. It’s an ugly hack but properly extracting DocuComments from C code is hard. The alternative would be to maintain separate POD files. (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.)
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.
Nick
Re: [lucy-dev] 0.4 release?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 23, 2014 at 10:03 AM, Peter Karman <pe...@peknet.com> 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.
Marvin Humphrey