Hi Anirudh,

Thanks a lot for your clarifications! I have some followup
questions/comments:

1) Which guideline should we follow when updating the UI in MXNet operators?
A) MXNet follows semantic versioning, so breaking changes to operator
interfaces can be introduced only in major versions.

(Lin:) My question is what style of UI guide we should follow. e.g. naming
convension, usage mode, etc. Something like numpy's style or tensorflow?

2) Who should approve the UI change?
A) Contributors who may have worked on the operator and/or other
contributors/committers.

(Lin:) Is it too local to reply on contributors to one/a few operators to
decide the UI. How can we make sure the consistency of UI across all
operators in MXNet?

3) In case of backward compatibility, should we favor breaking the backward
compatibility and update the release notes or adding a newer version of the
operator like ***_v2?
A) If the operator interfaces are not compatible, its fine to create
operator with the name "_v2" . In the next major version release, you can
add an alias for newer implementation and deprecate the older one.

(Lin) What if there is already "_v2", do we add "_v3", "_v4" as the project
evolves?

4) Which operator should go to contrib and which be implemented as regular?
A) I think this discussion may help:
https://github.com/apache/incubator-mxnet/pull/5499 . To summarize: contrib
was created for ops for which we provide limited guarantees with respect to
backward compatibility, interface changes, testing etc.

(Lin) This is definitely an informative discussion. It would be better if
we can put this in a more noticeable place for developers.


On Thu, Dec 20, 2018 at 1:39 PM Anirudh Subramanian <anirudh2...@gmail.com>
wrote:

> 1) Which guideline should we follow when updating the UI in MXNet
> operators?
> A) MXNet follows semantic versioning, so breaking changes to operator
> interfaces can be introduced only in major versions.
>
> 2) Who should approve the UI change?
> A) Contributors who may have worked on the operator and/or other
> contributors/committers.
>
> 3) In case of backward compatibility, should we favor breaking the backward
> compatibility and update the release notes or adding a newer version of the
> operator like ***_v2?
> A) If the operator interfaces are not compatible, its fine to create
> operator with the name "_v2" . In the next major version release, you can
> add an alias for newer implementation and deprecate the older one.
>
> 4) Which operator should go to contrib and which be implemented as regular?
> A) I think this discussion may help:
> https://github.com/apache/incubator-mxnet/pull/5499 . To summarize:
> contrib
> was created for ops for which we provide limited guarantees with respect to
> backward compatibility, interface changes, testing etc.
>
> Anirudh
>
> On Thu, Dec 20, 2018 at 1:00 PM Lin Yuan <apefor...@gmail.com> wrote:
>
> > Dear Community,
> >
> > As a contributor, I would like to know the current policy for updating UI
> > of an operator. I understand UI change should be introduced in major
> > release not minor release. However, it is still not quite clear to me
> > regarding the UI change process:
> >
> > 1) Which guideline should we follow when updating the UI in MXNet
> > operators?
> > 2) Who should approve the UI change?
> > 3) In case of backward compatibility, should we favor breaking the
> backward
> > compatibility and update the release notes or adding a newer version of
> the
> > operator like ***_v2?
> > 4) Which operator should go to contrib and which be implemented as
> regular?
> >
> > Any clarification is appreciated and it is helpful to guide PR reviewers
> as
> > well.
> >
> > Merry Christmas to ya'all!
> >
> > Lin
> >
>

Reply via email to