**Problem**
Some scripted tests are failing due to the fact that -bin-SNAPSHOT
isn't being recognized.
**Solution**
This fixes sbtApiVersion to recognize BinCompatV.
- Add `versionSatisfiesRange()` function to `VersionRange.scala` supporting Maven-style ranges (`[x,y)`, `(x,y]`, `[x,)`, etc.) and plus ranges (`1.0+`)
- Check if winner version satisfies evicted module's version range in `guessCompatible()`
Add support for `"3-latest.candidate"` to automatically resolve to the latest Scala 3 RC from Maven Central.
```scala
scalaVersion := "3-latest.candidate"
```
Ref https://github.com/sbt/sbt/discussions/8590
* test: Migrate UpdateReportSpec to verify.BasicTestSuite (#8543)
Migrate UpdateReportSpec.scala from ScalaTest's AnyFlatSpec + Matchers
to verify.BasicTestSuite, following the pattern established by other
test files in the lm-core module.
Changes:
- Replace AnyFlatSpec class with BasicTestSuite object
- Remove ScalaTest Matchers dependency
- Convert 'should ... in' syntax to 'test(...)' syntax
- Use Scala 3 syntax with colon indentation
- Change === to == for assertions (BasicTestSuite style)
- Add explicit types for lazy vals
- Add 'end UpdateReportSpec' marker
Fixes#8543
* Update lm-core/src/test/scala/UpdateReportSpec.scala
---------
Co-authored-by: GlobalStar117 <[email protected]>
**Problem**
When project A's dependencies changed and A was compiled in one command, project B (depending on A) would not invalidate its update cache in a subsequent command. This caused stale classpaths.
The root cause was that `depsUpdated` only checked `!stats.cached`, which only detected fresh resolves within the same command. When a dependency was served from cache (even if resolved fresh in a previous command), `cached` was marked `true`, causing incorrect cache reuse.
Debug scenario from issue:
sbt:aaa> clean
sbt:aaa> a/compile
sbt:aaa> show itTests/depsUpdated
[info] * false <-- BUG: should be true
**Solution**
Added `stamp: String` field to `UpdateStats` that records when the update was resolved. This stamp persists across commands and enables accurate cross-command comparison:
- If any dependency's stamp > our cached stamp, we re-resolve
- Falls back to `!cached` check for backwards compatibility with old caches
- Using `String` type allows future transition from timestamps to content hashes
When using `ProjectMatrix` with `CrossVersion.full` and Scala 2 versions like `2.13.18`, the project ID incorrectly became `$1$2_13_18` instead of `foo2_13_18`.
**Root cause:** The Scala 3 compiler creates synthetic intermediate vals (e.g., `$1`) during macro expansion. The `enclosingTerm` function in the macros was stopping at these synthetic symbols instead of continuing up the symbol tree to find the actual val name.
**Fix:** Added `Flags.Synthetic` check to skip compiler-generated symbols in:
- `main-settings/src/main/scala/sbt/std/KeyMacro.scala`
- `lm-core/src/main/scala/sbt/librarymanagement/ConfigurationExtra.scala`
---------
Co-authored-by: byteforge38 <[email protected]>
Eviction warnings and errors were not reported for Test dependencies because
`EvictionError` only checked the Compile configuration.
This fix runs the eviction check for both Compile and Test configurations
separately, with distinct error messages:
- Compile: `found version conflict(s) in library dependencies`
- Test: `found version conflict(s) in Test dependencies`
**Problem**
During the milestone releases of Scala, e.g. Scala 2.13.0-M1,
scalaBinaryVersion by design points to 2.13.0-M1,
and also the source directory uses scala-2.13.0-M1,
but in most cases we actually want to pretend compatibility
and use scala-2.13 directory.
**Solution**
This introduces a new setting called scalaEarlyVersion,
which is the scalaBinaryVersion of the release version of milestones.
We have been calling this "partial version", but that broke
down for Scala 3, which adopted semantic versioning.
The current deprecation messages for `sonatypeRepo()` & `sonatypeOssRepos()` (added with https://github.com/sbt/librarymanagement/pull/517) say:
> use the following instead: resolvers += Resolver.sonatypeCentral**Snapshots**
...but following this advice can expose projects to using **snapshot** artifacts when they did not previously! This is unfortunate, as snapshots artifacts are inherently more risky, due to being mutable.
For example, invocations of `sonatypeOssRepos()` like [this](https://github.com/guardian/frontend/blob/76234e013f550ac600fbf0bb924c19a1a6165295/project/plugins.sbt#L10):
```scala
resolvers ++= Resolver.sonatypeOssRepos("releases")
```
...should _not_ be replaced by `sonatypeCentralSnapshots()`, as, AFAIK, only non-snapshot releases would be in `sonatypeOssRepos("releases")`
eugene yokota
calm
E.GandGlobalStar117
byteforgeandbyteforge38
kenji yoshida
Hamza Remmal
Roberto Tyley
Josh Soref
Matthew de Detrich
Adrien Piquerez