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.

Sign up for GitHub

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

Jump to bottom

Rewrite the Ivy revisions section #1206

Merged
merged 2 commits into from
Apr 26, 2024
Merged

Rewrite the Ivy revisions section #1206

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a15af1b
Rewrite the Ivy revisions section
eed3si9n Apr 24, 2024
55ef0a5
Edit
eed3si9n Apr 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 16 additions & 22 deletions src/reference/guide/08-Library-Dependencies.md
View file
Open in desktop
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.
Transitive version ranges could lead to surprising behavior where the effective version changes over time,
even when there is a specific version of the library within the version range in `build.sbt`.
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