On Thu, Dec 20, 2018, 1:56 PM Lin Yuan <apefor...@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 <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 > > > > > >
