Q: Should this library really declare a strict versionScheme?

[olegbonar]

Looks like ThisBuild / versionScheme := Some("strict") is set in build.sbt which means, according to sbt documentation, that it does not impose any compatibility guarantees between releases.

So, one could stuck in a situation when two independent libraries brings (transitively) two different zstd-jni versions (i.e. v1.5.6-4 and v1.5.6-5) to the classpath. In that case, sbt will error out and the conflict will need to be resolved.

So the question is - is this really necessary to declare versionScheme as strict? Are the patch releases really not compatible with one another?

[luben]

Good question. I should read more about the versionScheme

[luben]

OK, let's try with PVP versioning scheme - this will let us break binary compatibility on upstream minor releases, e.g when 1.6.0 is released next.

The only risk I see here (and with all other schemes) is that when we add new methods/classes we increase the "release" version for example A.B.C-release. We do that so A.B.C is the upstream zstd version we use. If the release is interpreted as part of the "patch" version, i.e. C in the example, it will work as expected. But this is not clear how SBT uses it, as PVP spec warns against using them: https://pvp.haskell.org/#version-tags

[luben]

released with v1.5.6-6

[olegbonar]

Also, publish the new tag if it's not too much trouble. Thanks!

[luben]

done