Publish `versionScheme`

In 1.5.0 sbt has introduced eviction errors. It would be nice if circe could publish versionScheme to fail builds when incompatible circe versions are present in dependencies.

Can we set versionScheme to early-semver for circe?

I’d be glad to make a PR if needed.

[armanbilge]

I see, thanks for that pointer. I was not aware that users were expected to rely on that. Although that may have been true that core 0.14.0 was binary-compatible with core 0.13.x, this relationship is not currently enforced in CI so it is not something you should count on.

Note that just because 0.14.x is binary-compatible with 0.14.0, and 0.14.0 is binary-compatible with 0.13.x, does not mean that 0.14.x is binary-compatible with 0.13.x. This is because public APIs in 0.13.x may have become private in 0.14.0 (but kept for bincompat) and subsequently changed/removed without realizing their purpose. For the record, I’m not aware of such a situation, but it’s not impossible.

This is why it is important that libraries check binary-compatibility against all previous versions they intend to stay binary-compatible with. Not just the last release (which unfortunately is what I see many projects doing).

I think that in the long term, circe should “schism” from mono-repo into several smaller repositories for each module. This would allow an individual module to make breaking changes, and publish under a new version, without forcing core to bump its version as well.

See also, http4s which recently went through a similar change. https://github.com/http4s/http4s/releases/tag/v0.23.12

[adamnfish]

The trouble is that right now the ecosystem depends on compatibility between 0.13.x and 0.14.x but adding a versionScheme would explicitly instruct tools to consider these as incompatible. As far as I can see, none of the supported version schemes would treat these two versions as compatible so we’d be needing circe to move to a new version anyway. If that’s happening, then it ought really switch to 1.x so that in the future these backwards-compatible changes can be properly conveyed by the chosen scheme.

In the absence of a version scheme the current ambiguity is “ok but annoying” (as ok as any JVM eviction!), but adopting a version scheme should always come with a commitment to stick properly to that scheme in future.