From 88ae163578da028f900b68f589f94889472e1fc0 Mon Sep 17 00:00:00 2001 From: Ricardo Martins Date: Wed, 10 Jan 2018 10:10:46 +0000 Subject: [PATCH] Fixed copy paste error --- .../tutorials/binary-compatibility-for-library-authors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_overviews/tutorials/binary-compatibility-for-library-authors.md b/_overviews/tutorials/binary-compatibility-for-library-authors.md index f88e740e94..cc8cd49ea5 100644 --- a/_overviews/tutorials/binary-compatibility-for-library-authors.md +++ b/_overviews/tutorials/binary-compatibility-for-library-authors.md @@ -198,7 +198,7 @@ Some examples: * `v1.0.0 -> v1.0.1` is source and binary compatible. This is a safe upgrade that does not introduce binary or source incompatibilities. * `v0.4.0 -> v0.5.0` is binary incompatible. End users and library maintainers need to update all their dependency graph to remove all dependency on `v0.4.0`. -* `v0.4.0 -> v0.4.1` is binary compatible. Classpath can safely contain both `v1.0.0` and `v1.1.0`. End user may need to fix minor source breaking changes introduced +* `v0.4.0 -> v0.4.1` is binary compatible. Classpath can safely contain both `v0.4.0` and `v0.4.1`. End user may need to fix minor source breaking changes introduced Many libraries in the Scala ecosystem has adopted this versioning scheme. A few examples are [Akka](http://doc.akka.io/docs/akka/2.5/scala/common/binary-compatibility-rules.html), [Cats](https://github.com/typelevel/cats#binary-compatibility-and-versioning) and [Scala.js](https://www.scala-js.org/).