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 <[email protected]> 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 <[email protected]> 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 > > >
