Hi Lin, generally I agree that we should try to not impact downstream projects.
One issue I see with this situation is how we consider the C API. My understanding so far was that it is exclusively considered an internal API that allows us to develop the frontend packages in a more streamlined way. This is enforced by running the various frontend languages in our CI. For native use-cases, I was under the impression that the cpp package is the interface we offer to the user and third parties. An analogy could be like the NTAPI in Windows - some are documented, some are not - they are accessible, but have no guarantee attached to them. They are merely a construct that allows Microsoft to connect their user-space applications to communicate with the kernel. Enforcing an API guarantee on the c api could harm the agility in the project, since changes are frequently needed to evolve. Ensuring comparability is then done on the frontend level. I'm not sure if we ever documented this separation properly, but my preference would be to continue to consider the c api internal and ask third parties to please use the officially supported frontend languages with their SemVer guarantees. Also, what roadmap discussion are you referring to? Is there some type of archive where we can read up on previous discussions? This sounds like some face to face meeting type. Best regards, Marco Lin Yuan <apefor...@gmail.com> schrieb am Di., 14. Jan. 2020, 01:38: > 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 >
