You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by Lin Yuan <ap...@gmail.com> on 2018/12/20 21:00:31 UTC
[Question] UI change policy in MXNet
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
Re: [Question] UI change policy in MXNet
Posted by Anirudh Subramanian <an...@gmail.com>.
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 <ap...@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
> > >
> >
>
Re: [Question] UI change policy in MXNet
Posted by Lin Yuan <ap...@gmail.com>.
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 <an...@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 <ap...@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
> >
>
Re: [Question] UI change policy in MXNet
Posted by Anirudh Subramanian <an...@gmail.com>.
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 <ap...@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
>