I wonder if it is possible to just use the RFC mechanism for most API change discussions.
Note that while API compatibility is important, having a clear RFC mechanism would likely strike a balance between the need to evolve APIs (e.g. 2.0) and stability of the project TQ On Mon, Jan 13, 2020 at 4:38 PM Lin Yuan <apefor...@gmail.com> wrote: > Dear Community, > > Recently, there were some changes to C APIs that broke another downstream > project Horovod: https://github.com/apache/incubator-mxnet/issues/17292. > Since we do not have integration tests for downstream project, it becomes > critical for us to update APIs with extreme caution. > > I would like to propose the following mechanism for us to maintain a clean > and robust APIs: including both C API and Python API at the moment. > > (1) Any PR involving change of APIs should be approved by at least one of > the committers from a "API Committee" before it can be merged. I will > explain how to form this committee at the end of email > > (2) Any PR that contains API change should clearly state this in PR title. > Otherwise, committer can reject the PR > > API Committee: > - This committee should consist of both seasoned MXNet developers and > users. > - Committee members should have a comprehensive view of MXNet APIs to make > sure their usage are consistent across stack. > - Committee members review PRs that involve API change with extra caution. > - Committee members are required to attend the roadmap discussion for each > new release. > - For API breaking changes, committe members should reach consensus before > the change is made. > > Any other suggestion is welcome here. > > Best, > > Lin >
