Open lolgab opened 7 months ago
Thank you @lolgab for the write up.
I agree this problem should be addressed. I remember scala-xml was in a similar situation when they decided to release a 1.0.0 version.
I think a sister issue should be created in the sbt repository to make sure sbt correctly interprets info.backwardsBinaryCompatibleWith
. Maybe a similar issue should be created in the other Scala build tools?
Note that it is possible to do what you want today already:
versionPolicyIntention := Compatibility.BinaryCompatible
in your 0.x branchversionPolicyCheck
in the CIprojectID ~= { id =>
val backwardsCompatibilityInfo = "info.backwardsBinaryCompatibleWith" -> "0.3"
id.withExtraAttributes(id.extraAttributes + backwardsCompatibilityInfo)
}
We could probably automate the part the configures the projectID
key in sbt-version-policy, though, but that needs to be investigated further.
Sometimes a stable library in its
0.x
version decides to release a stable1.x
version since it has a stable API and it wants to communicate with its users. According to versioning scheme these two libraries are not binary compatible. However, sometimes the 1.x version is backward compatible with the previous0.x
release. This feature request is about adding a new field in the library pom of the new version to state that is compatible with the older binary version. In the example of cats-parse. It should contain a new field inproperties
, like<info.backwardsCompatibleWith>0.3</info.backwardsCompatibleWith>
Whencats-parse
1.0.0
and0.3.10
are resolved Sbt should not report any warning since they are binary compatible with each other.This issue was first reported in Typelevel Discord by @s5bug