Skip to content

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

@bpholt

Description

@bpholt

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions