From sbt/sbt#7609.
The different behavior depending on if "update" task is invoked or not seems a bug.
Also, I believe that even the current implementation of Ivy that SBT is using will default to latest revision and not nearest neighbor like Apache Maven. I could try to create a reproductible example showing this if necessary. But, from experience, this is what happens, except in this particular case for scala-collection-compat_2.12 artifact.
I went further and took a look at the cached ivyModule.xml files for each 2.1.2 and 2.4.4 version of the artifact. I noticed that the version schema used for 2.4.4 was defined as early-semver. And, for 2.1.2, the schema was not defined so I assumed the default was used: always. Maybe this could be a reason for this different behavior depending on the tasks invoked and if the artifacts were cached already.
From sbt/sbt#7609.
The different behavior depending on if "update" task is invoked or not seems a bug.
Also, I believe that even the current implementation of Ivy that SBT is using will default to latest revision and not nearest neighbor like Apache Maven. I could try to create a reproductible example showing this if necessary. But, from experience, this is what happens, except in this particular case for
scala-collection-compat_2.12artifact.I went further and took a look at the cached ivyModule.xml files for each
2.1.2and2.4.4version of the artifact. I noticed that the version schema used for2.4.4was defined asearly-semver. And, for2.1.2, the schema was not defined so I assumed the default was used:always. Maybe this could be a reason for this different behavior depending on the tasks invoked and if the artifacts were cached already.