You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it seems like there are no plans to break binary compatibility anytime soon. As such, it would make it easier on downstream users for newtypes-core to use regular semver instead of early-semver.
For example, under early-semver rules, v0.3.0 is a major release, meaning any libraries previously depending on v0.2.x must now themselves release a new major version.
Similarly, sbt will reject the version mismatch if anything in the dependency graph uses the old version:
found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
* io.monix:newtypes-core_2.13:0.3.0 (early-semver) is selected over {0.2.3}
but this is not optimal as this kind of workaround tends to live longer than it needs to, and means if the library does need to introduce binary-incompatible changes, those applications will not indicate the potential failure at build time.
I'm unclear what was meant to have been signaled by the release of v0.3.0; since it didn't contain any binary-incompatible changes, I would have expected it to have been released as v0.2.4. That can't be changed at this point, but I think we can prevent future such issues by releasing v1.0.0.
The text was updated successfully, but these errors were encountered:
Given the binary compatibility guarantees in place via
newtypes/build.sbt
Lines 46 to 51 in 7fe3003
newtypes-core
to use regular semver instead of early-semver.For example, under early-semver rules,
v0.3.0
is a major release, meaning any libraries previously depending onv0.2.x
must now themselves release a new major version.Similarly, sbt will reject the version mismatch if anything in the dependency graph uses the old version:
It's always an option for users to add
but this is not optimal as this kind of workaround tends to live longer than it needs to, and means if the library does need to introduce binary-incompatible changes, those applications will not indicate the potential failure at build time.
I'm unclear what was meant to have been signaled by the release of
v0.3.0
; since it didn't contain any binary-incompatible changes, I would have expected it to have been released asv0.2.4
. That can't be changed at this point, but I think we can prevent future such issues by releasingv1.0.0
.The text was updated successfully, but these errors were encountered: