Skip to content

v6.0.0

Latest

Choose a tag to compare

@shadowsmind shadowsmind released this 07 Nov 12:35
· 2 commits to main since this release

mongo4s 6.0.0

mongo4s moves to the now.sendline organization. The code and API are the same as in 5.1.1, and the package is
still mongo4s. MiMa checks every module against org.mongo4s 5.0.0 and 5.1.1 and finds nothing. The upgrade is
one line in build.sbt.

libraryDependencies += "now.sendline" %% "mongo4s-core" % "6.0.0"

Moving from 5.1.x

// before
"org.mongo4s" %% "mongo4s-cats" % "5.1.1"
// after
"now.sendline" %% "mongo4s-cats" % "6.0.0"

A build tool treats a new organization as a new library and will not evict one in favour of the other. If something
in your graph still brings in org.mongo4s 5.x, both jars carry the same classes, and which one loads depends on
classpath order. Move that dependency as well, or exclude the old organization:

libraryDependencies += ("com.example" %% "internal-commons" % "1.2.3").excludeAll(ExclusionRule("org.mongo4s"))

org.mongo4s 6.0.0 is published as a Maven relocation: one pom per module that points to now.sendline, with no
jar. A build that only bumps the version to 6.0.0 therefore resolves to the new organization, in Maven and in sbt
through Coursier. Maven also prints the relocation message saying where mongo4s moved. Nothing more will be
published under org.mongo4s.

Where things are now

  • Repository: Sendline-now/mongo4s. The old URLs redirect.
  • Site: oss.sendline.now/mongo4s, shared with logging4s and metrics4s and
    built from this README. mongo4s.org redirects there.
  • A new logo, in light and dark versions.

Why a major version

Nothing in the API changed. The version is major because switching the organization means editing build.sbt by
hand, and a version bump that looks routine would hide that. The reasoning is in
DESIGN.md, and the migration guide is in
COMPATIBILITY.md.