Hi,
The semantics around how we should treat SNAPSHOT is so complicated that my general recommendation is
keep the use of SNAPSHOT only to the testing using local machines, and use other strategy like Git sha versioning
the moment your artifact leaves your machine.
We can think of a few goals around sbt's dependency resolution:
1. Do not run dependency resolution unless we need to, so running `compile` should not result to full resolution each time.
b. Variant here is starting up sbt from terminal repeatedly, which might result to sbt itself or plugin getting resolved.
2. -SNAPSHOT versioned module should resolve to the latest artifact based on its publish date.
If we are ambitious, we can even throw in:
3. sbt should have build-wide or machine-wide knowledge of the freshness so 100 subprojects should not result to 100 checks.
In any case, `update` task by default caches the result of resolution in `target` for goal 1.
It behaves differently when `update` is called transitively via `compile` or if you explicitly invoked `update`.
Try running `clean` to clear out task caching to double check around this.
The second and more tricky part is goal 2. Where is your library B published to?
Is it published to both local and remote repositories? If it's Maven repository, is the meta data up to date?
Also have you made sure that UpdateOptions.withLatestSnapshots is not set to false?
Towards goal 3, we can think of putting TTL (time to live) around SNAPSHOT cache, and cached resolution.
Coursier sets TTL to 24h by default if I understand correctly. cached resolution bumps the clock every time you call `update`,
so subproject re-resolution doesn't occur.
-eugene