Using @Unstable more often

[Brian Cho <ch...@gmail.com>]

Hi,

Working on NetworkConnectionService (REEF-610), we’ve found the overhead of
dealing with deprecation to be significant. I’ve also noticed some other
traffic on JIRA/Github referring to just removing things instead of
deprecating.

I was thinking there has to be a better way, and it looks like we already
have one: the @Unstable annotation! Actually, now that I look at it John is
already one step ahead of me — Vortex is using @Unstable well.

So, it looks like my point is: for those of you who don’t know, @Unstable
should be used when writing up features that we know to be unstable. I
might eventually file a JIRA to retroactively label NCS as @Unstable,
although it’s getting more stable every day ;)

Another thing to think of: using @Unstable well will probably help us if we
eventually shorten our release cycles.

Thanks,
Brian

Re: Using @Unstable more often

[Markus Weimer <ma...@weimo.de>]

+1

On the Java side, we also have @Private to mark code that for packaging
reasons has to be `public`, but is not meant to be used by either
application or runtime authors. We should use it more often as well.

In C#, I have recently grown quite fond of the `internal` access
modifier. It means that a specific API is only available for callers in
the same assembly. Further, you can dedicate friend assemblies (e.g. the
tests) to have access. This, together with Tang, allows us to use the
following neat pattern where almost nothing is public:

  * Every component has a `public` namespace `API`.
  * Every implementation of that API is `internal` but also comes with
    a `public` ConfigurationModule.

I've used this pattern in the `IFileSystem` space and quite like it.

Markus



On 2015-08-21 08:51, Andrew Chung wrote:
> +1 for @Unstable. The driver restart code for the YARN runtime has been
> using it extensively as well.
> 
> Thanks,
> Andrew
> 
> On Fri, Aug 21, 2015 at 4:35 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> 
>> Brian,
>>
>> Thanks for bring up this issue.
>> I totally agree that we have to use @Unstable more for new features to
>> avoid handling deprecated code too much.
>> I suggest we delete the deprecated part in NCF/NCS right away since
>> NCF/NCS's not used in the other part of REEF yet.
>>
>> Thanks!
>> -Gon
>>
>> On Fri, Aug 21, 2015 at 5:20 PM, Brian Cho <ch...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Working on NetworkConnectionService (REEF-610), we’ve found the overhead
>> of
>>> dealing with deprecation to be significant. I’ve also noticed some other
>>> traffic on JIRA/Github referring to just removing things instead of
>>> deprecating.
>>>
>>> I was thinking there has to be a better way, and it looks like we already
>>> have one: the @Unstable annotation! Actually, now that I look at it John
>> is
>>> already one step ahead of me — Vortex is using @Unstable well.
>>>
>>> So, it looks like my point is: for those of you who don’t know, @Unstable
>>> should be used when writing up features that we know to be unstable. I
>>> might eventually file a JIRA to retroactively label NCS as @Unstable,
>>> although it’s getting more stable every day ;)
>>>
>>> Another thing to think of: using @Unstable well will probably help us if
>> we
>>> eventually shorten our release cycles.
>>>
>>> Thanks,
>>> Brian
>>>
>>
>>
>>
>> --
>> Byung-Gon Chun
>>
> 

Re: Using @Unstable more often

[Andrew Chung <af...@gmail.com>]

+1 for @Unstable. The driver restart code for the YARN runtime has been
using it extensively as well.

Thanks,
Andrew

On Fri, Aug 21, 2015 at 4:35 AM, Byung-Gon Chun <bg...@gmail.com> wrote:

> Brian,
>
> Thanks for bring up this issue.
> I totally agree that we have to use @Unstable more for new features to
> avoid handling deprecated code too much.
> I suggest we delete the deprecated part in NCF/NCS right away since
> NCF/NCS's not used in the other part of REEF yet.
>
> Thanks!
> -Gon
>
> On Fri, Aug 21, 2015 at 5:20 PM, Brian Cho <ch...@gmail.com> wrote:
>
> > Hi,
> >
> > Working on NetworkConnectionService (REEF-610), we’ve found the overhead
> of
> > dealing with deprecation to be significant. I’ve also noticed some other
> > traffic on JIRA/Github referring to just removing things instead of
> > deprecating.
> >
> > I was thinking there has to be a better way, and it looks like we already
> > have one: the @Unstable annotation! Actually, now that I look at it John
> is
> > already one step ahead of me — Vortex is using @Unstable well.
> >
> > So, it looks like my point is: for those of you who don’t know, @Unstable
> > should be used when writing up features that we know to be unstable. I
> > might eventually file a JIRA to retroactively label NCS as @Unstable,
> > although it’s getting more stable every day ;)
> >
> > Another thing to think of: using @Unstable well will probably help us if
> we
> > eventually shorten our release cycles.
> >
> > Thanks,
> > Brian
> >
>
>
>
> --
> Byung-Gon Chun
>

Re: Using @Unstable more often

[Byung-Gon Chun <bg...@gmail.com>]

Brian,

Thanks for bring up this issue.
I totally agree that we have to use @Unstable more for new features to
avoid handling deprecated code too much.
I suggest we delete the deprecated part in NCF/NCS right away since
NCF/NCS's not used in the other part of REEF yet.

Thanks!
-Gon

On Fri, Aug 21, 2015 at 5:20 PM, Brian Cho <ch...@gmail.com> wrote:

> Hi,
>
> Working on NetworkConnectionService (REEF-610), we’ve found the overhead of
> dealing with deprecation to be significant. I’ve also noticed some other
> traffic on JIRA/Github referring to just removing things instead of
> deprecating.
>
> I was thinking there has to be a better way, and it looks like we already
> have one: the @Unstable annotation! Actually, now that I look at it John is
> already one step ahead of me — Vortex is using @Unstable well.
>
> So, it looks like my point is: for those of you who don’t know, @Unstable
> should be used when writing up features that we know to be unstable. I
> might eventually file a JIRA to retroactively label NCS as @Unstable,
> although it’s getting more stable every day ;)
>
> Another thing to think of: using @Unstable well will probably help us if we
> eventually shorten our release cycles.
>
> Thanks,
> Brian
>



-- 
Byung-Gon Chun