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 >
