mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anirudh Subramanian <anirudh2...@gmail.com>
Subject Re: [Question] UI change policy in MXNet
Date Thu, 20 Dec 2018 22:14:23 GMT
On Thu, Dec 20, 2018, 1:56 PM Lin Yuan <apeforest@gmail.com wrote:

> 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?
>
I don't think there is such an UI guide. If the operator already existed in
numpy/scipy or other frameworks we generally tend to use similar
interfaces.

>
> 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?
>
agreed. Feel free to propose a better way.

>
> 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?
>
This needs to be dealt on case by case basis. I haven't seen many ops which
would require three backward incompatible revisions between two major
releases.

>
> 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 <anirudh2290@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 <apeforest@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message