0

Some widely used libraries are still versioned 0.x, which under semantic versioning, means they might break the API at any time. Examples of such libraries:

There are many popular libraries with dependencies on numba, pandas, scikit-learn, or countless other not-quite-as-popular pre-1.0 dependencies, that themselves have reached v1.0, guaranteeing certain API stability when the major version number doesn't change.

It would seem to me that it's not possible to make such a guarantee when the dependencies don't. Does that mean that under semantic versioning, strictly speaking, a library can only reach v1.0 when all its (important) dependencies have?

gerrit
  • 1,090
  • 1
  • 8
  • 21

2 Answers2

5

It would seem to me that it's not possible to make such a guarantee when the dependencies don't.

There are many different ways to make such a guarantee. In fact, why would changing the API of an internal dependency affect the external API at all?

If I have a public API: add(a, b) -> returns the sum of a and b and implement it using a third-party dependency like this a + b, and the third-party changes their API to use words instead of operator symbols, I simply change the internal implementation to be like this plus(a, b) and nothing in my public API changes.

A second way to guarantee API stability would be to simply not update the dependency.

A third way would be to update your major version every time a dependency breaks its API.

A fourth way would be to fork the dependency and keep the API stable.

For example, many Linux distributions have Long-Term Support releases that promise backwards-compatibility, bug fixes, and security fixes far longer than the authors of the packages that are part of the distribution do. The distribution developers simply take up maintenance of those packages themselves when the upstream developers move to an incompatible version.

Jörg W Mittag
  • 103,514
0

The semantic versioning guarantee applies to the code within a library. It says, "as long as you use some version of mylib 1.*, your client code will not have to change."

But each of the 1.X versions can have dependencies on third-party software. As I read the definition of SV, there's no reason why these dependencies can't be "you need exactly libfoobar 0.46 to run mylib 1.2".

Kilian Foth
  • 109,273
  • What I mean is, how can mylib 1.2 keep its promise if libfoobar 0.46 breaks its API breaking essential features in mylib 1.2? If libfoobar removes a class or function that is essential for mylib to function? – gerrit Nov 08 '19 at 10:43
  • 2
    libfoobar 0.46 will never break its API. libfoobar 0.47 may break libfoobar 0.46's API, but then you simply don't update. – Jörg W Mittag Nov 08 '19 at 10:44