Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

MXNet extensions semantic versioning #19135

Open
samskalicky opened this issue Sep 13, 2020 · 2 comments
Open

MXNet extensions semantic versioning #19135

samskalicky opened this issue Sep 13, 2020 · 2 comments

Comments

@samskalicky
Copy link
Contributor

samskalicky commented Sep 13, 2020

Description

Currently the lib_api.h has a version number in it that is required to match the one in MXNet when loading the library.

Every change increments the version number:
https://github.com/apache/incubator-mxnet/blob/f1acda73e0b2ca5f1b6ff89f25c17a838819be82/include/mxnet/lib_api.h#L56
And the version number is required to match:
https://github.com/apache/incubator-mxnet/blob/f1acda73e0b2ca5f1b6ff89f25c17a838819be82/src/c_api/c_api.cc#L1500-L1503
Each release of MXNet will require libraries to have the same version of lib_api.h. The versioning of the Extensions APIs is different than MXNet's C API.

This simplifies testing and ensures that libraries will work with a specific version of MXNet. It also allows the APIs to evolve without being restrained.

Starting in the 2.0 release onwards, should we change this to follow semantic versioning? And if so, how do we test and verify the compatibility hasnt been broken? How do we ensure that for future major releases we can break compatibility and check and report incompatibility errors?

@szha
Copy link
Member

szha commented Sep 13, 2020

In general, features in MXNet must follow semantic versioning. This means that if a feature is offered as an official, non-experimental API in a release, then backward-incompatible change to it is no longer allowed in future revision. This applies to both 1.x and 2.x.

Specific to the recent changes in extensions in #19117, it looks they fall in the category of adding functionality. One way to make it work is to only add new API without changing existing API. @samskalicky would this approach work?

@samskalicky
Copy link
Contributor Author

In previous 1.x releases we're been terribly inconsistent:

Lets focus the discussion on how to do things better for 2.0.

We'll probably need to keep the version number (to avoid backward incompatible libraries from earlier versions). But I guess we can stop incrementing it for minor releases and do as you suggest on API changes to enable backwards compatibility for 2.x minor versions.

And then in major version changes we can increment the version number to demarcate backward incompatibility.

What do you think?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants