Publish versionScheme in sbt

[majk-p]

The 1.5.0 version of SBT is getting closer, and with this release the behavior of evictions is changing. There's been a discussion (sbt/sbt#6221 (comment)) on this topic. Since 1.5.0 SBT would warn the versionScheme is not published. If tapir doesn't publish it, users will have to guess it and set it on their own.

In my opinion the sooner tapir (and other libs as well) publish this, the easier will the migration to 1.5.0 be.
Can we please define and publish the versioningScheme?

@adamw please have a look

[adamw]

Sure ... what are the possibilities?

Though I don't think we can do any better than "any". Like sttp client, tapir is an integration project, and keeping binary compatibility between versions can be at least challenging. I think there might be too many dependencies for each of the modules.

[majk-p]

The original proposal mentions 5 options:

The following compatibility types are available:

• early-semver: assumes the matched modules follow a variant of Semantic Versioning
  that guarantees backward binary compatibility between minor releases (e.g., 1.1.1 and 1.2.0),
  and between patch releases if the major version number is 0 (e.g., 0.7.2 and 0.7.3).
• semver-spec: assumes the matched modules follow Semantic Versioning,
  which guarantees backward binary compatibility between minor releases (e.g., 1.1.1 and 1.2.0),
  but does not guarantee any compatibility between patch releases if the major version number
  is 0 (e.g., 0.7.2 and 0.7.3).
• pvp: assumes the matched modules follow package versioning policy (quite common in Scala),
• always: assumes all versions of the matched modules are compatible with each other,
• strict: requires exact matches between the wanted and the selected versions of the matched modules.

If it's possible - I'd love it if tapir provided early-semver (so it would be guaranteed that 17.18 is compatible with 17.x). I guess running some mima compatibility check to decide if we should bump minor or patch.
If it's too hard to maintain, then I guess strict is still an option.

[adamw]

Maybe we can do it on a module-per-module basis? E.g. for core I think we could try early-semver. Others ... not so sure, they are at a different level of maturity. And yes, that would require re-enabling and properly configuring mima so that this is automatically checked.

[majk-p]

Sounds like a plan. I'd have to think what are the downsides for this, any trouble on client side, but nothing comes to my mind at the moment. I'd like to hear more opinions from users, if they have any expectations/wishes regarding the versioning.

As always I'm happy to help with implementing that if needed.

[matwojcik]

I'd love tapir (or sttp) to be released in more predictable way, so early-semver/semver-spec. Current state is that it breaks in patch versions even (I'm not saint here, at least twice I contributed breaking changes). It makes it problematic to use those, especially if someone builds some common library on top of tapir/sttp (which we do).

Module-per-module - it may work I believe, however some deep analysis how to play with mima would be required.

[kubukoz]

👍 for per-module basis and MiMa in the modules that have anything else than "strict".

[adamw]

I think a good starting point would be to have a task which would run mima using the correct "previous version", in cooperation with sbt-dynver. Then we could plug in into GH Actions and get a nice report if there's a problem.

If somebody could work on that, would be great:) Help always appreciated

[majk-p]

I'm not 100% if it looks good, but I've prepared a PR for this #1129

[adamw]

I think the PR solved this, at least for core