Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release newtypes-core v1.0 to upgrade version schemes #167

Open
bpholt opened this issue Sep 13, 2024 · 0 comments
Open

Release newtypes-core v1.0 to upgrade version schemes #167

bpholt opened this issue Sep 13, 2024 · 0 comments

Comments

@bpholt
Copy link

bpholt commented Sep 13, 2024

Given the binary compatibility guarantees in place via

newtypes/build.sbt

Lines 46 to 51 in 7fe3003

val majorProjectSeries = "0.2.1"
def mimaSettings(projectName: String) = Seq(
mimaPreviousArtifacts := Set("io.monix" %% projectName % majorProjectSeries),
//mimaBinaryIssueFilters ++= MimaFilters.changesFor_3_0_1,
)
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}

It's always an option for users to add

ThisBuild / libraryDependencySchemes += "io.monix" %% "newtypes-core" % "always"

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant