Compatibility of pynvjitlink across versions

[jakirkham]

What kind of versioning scheme do we intend to use with pynvjitlink?

Do we intended to hold compatibility with major versions? So 1.x.y would be compatible with x increments for new features and y for bug fixes

Or do we intend to keep compatibility only within minor versions? So 1.2.y would be compatible for all y, but 1.3 would break compatibility?

Or do we have a different model of compatibility in mind?

cc @brandon-b-miller @gmarkall

[vyasr]

We should also think about what exactly constitutes the public API. Do we intend for consumers to use anything other than patch_numba_linker? Do we want to be exposing pynvjitlink.api.NvJitLinker? What about the methods of that class? If we want to make compatibility guarantees we should figure out these questions first.

[jakirkham]

We discussed this offline at length

The conclusion was we would like to use semantic versioning

For now we will keep the 0 based version, but plan to bump it to 1.0.0 in the next release

[gmarkall]

I'm not sure I'd want to declare "the next release will be 1.0.0" as I may have to make some changes in future for a non-RAPIDS use case, and wouldn't want to bump the version to 1.0.0 for that.