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

update library dependencies docs. #1203

Closed
wants to merge 1 commit into from
Closed

update library dependencies docs. #1203

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
6 changes: 3 additions & 3 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 @@ -171,10 +171,10 @@ 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.
over time, even though there's a specified version of the library in the build
but it doesn't satisfy the range condition.
Comment on lines -174 to +175
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is correct. Here's the surprise in bullet points:

  • The build specifies a version number, which satisfies the range condition.
  • Given the range condition, Coursier or Ivy would go out to the Internet to find the latest version in the range.
  • If there's a new version found from the Internet that satisfies the range condition, Coursier or Ivy would use the newly found version, ignoring what the user has specified.
  • This can change the behavior of your software.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, if "The build specifies a version number, which satisfies the range condition", then the sbt uses the specfied version.
on the other hand, if the build does NOT specify a version number, Coursier could go to internet and get changing latest version, which could be surprising to the build author.

i think we should rewrite the doc to remove the even though part:

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 in the build
but it doesn't satisfy the range condition.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eed3si9n lmk what do you think. thanks for reviewing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's my take on the rewrite - #1206

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commented there .


Maven version ranges will be replaced with its lower bound if the
Maven version ranges will be replaced with its lower bound in 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`.
Expand Down
Loading