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 21:39:15 GMT
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