You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2014/07/01 05:07:52 UTC
Re: [lucy-dev] 0.4 release?
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 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