What are the best practices to do semver (semantic versioning) of a wrapper library?

Question

I'm thinking of adopting semver for a wrapper of another library that also follows semver. Originally I thought I would just keep the version of the wrapper the same as the original library, as ideally they would be exactly matched all the time.

However, this is not so simple, as there may be bugs and patches to the wrapper itself that have nothing to do with the original library, not to mention the wrapper development itself is incremental and not all functionality springs out ready made overnight.

What would be the recommended way to do versioning of this wrapper to take into account BOTH the version of the original library that the wrapper refers to AND the patches and development history of the wrapper itself?

Answer 1

Version your wrapper independently from the library. Your version number should indicate changes to your wrapper code. The library is a dependency for your wrapper, just like any other library dependencies. Maintain a table listing compatibility between versions of your wrapper and versions of the library.

If you don't like the idea of having your wrapper at version 1.1.0 while the library is at 4.3.2, consider adding a "marketing" version number to your wrapper. Your wrapper could be called "Wrapper 4" to indicate that it is compatible with version 4 of the library, but internally you could still identify your wrapper's exact version as 1.1.0.