Skip to content

Commit

Permalink
Rewrite the Ivy revisions section
Browse files Browse the repository at this point in the history
  • Loading branch information
eed3si9n authored and lervag committed Sep 15, 2024
1 parent a36c3b7 commit f106eed
Showing 1 changed file with 16 additions and 22 deletions.
38 changes: 16 additions & 22 deletions src/reference/guide/08-Library-Dependencies.md
Original file line number Diff line number Diff line change
Expand Up @@ -153,32 +153,26 @@ to ensure binary compatibility.

See [Cross Building][Cross-Build] for some more detail on this.

#### Ivy revisions
#### Dynamic versions (Discouraged)

The `version` in `organization % moduleName % version` does not have to be a
single fixed version. Ivy can select the latest revision of a module
according to constraints you specify. Instead of a fixed revision like
`"1.6.1"`, you specify `"latest.integration"`, `"2.9.+"`, or `"[1.0,)"`. See the
[Ivy
revisions](https://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html#revision)
single fixed version.
Cousier and Ivy can select the latest revision of a module according to constraints you specify.
Instead of a fixed revision like
`"1.6.1"`, you specify `"latest.integration"`, `"2.9.+"`, or `"[1.0,)"`.
These dynamic versions might work one day, but break the next, and make the build non-repeatable.

A Maven version range such as `[1.3.0,)` can be used to specify a dependency,
and it can appear transitively in existing POM files. When a dependency manager
like Coursier finds a version range, it will go out to the Internet to find the latest version.
This could lead to surprising behavior where the effective version changes over time,
even when there is a specified version of the library within the version range.
Therefore, until sbt implements a lock file, we generally discourage the use of version ranges.

See the [Coursier version handling](https://get-coursier.io/docs/other-version-handling) and
the [Ivy revisions](https://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html#revision)
documentation for details.

<!-- TODO: Add aliases -->

Occasionally a Maven "version range" is used to specify a dependency
(transitive or otherwise), such as `[1.3.0,)`. If a specific version
of the dependency is declared in the build, and it satisfies the
range, then sbt will use the specified version. Otherwise, Coursier could
go out to the Internet to find the latest version. This would result
to a surprising behavior where the effective version keeps changing
over time, even though there's a specified version of the library that
satisfies the range condition.

Maven version ranges will be replaced with its lower bound if the
build so that when a satisfactory version is found in the dependency
graph it will be used. You can disable this behavior using the JVM
flag `-Dsbt.modversionrange=false`.

#### Resolvers

Not all packages live on the same server; sbt uses the standard Maven2
Expand Down

0 comments on commit f106eed

Please sign in to comment.