I don't remember how this is used but I'm a bit concerned that this is no longer used.

A copy of the method is declared here https://github.com/sbt/zinc/blob/028b12bef3c263d9f67dc648f5864868739f20bb/project/ZincBuildUtil.scala#L14-L36

And used here
https://github.com/sbt/zinc/blob/028b12bef3c263d9f67dc648f5864868739f20bb/build.sbt#L459-L462

Btw Eugene may I ask what might generateVersionFile method be originally used for? My current guess is that this is a crude archaic invalidation mechanism to generate a distinct incrementalcompiler.version.properties in target of compiler-interface to invalidate some unknown upstream cache (or analysis?).

Either way this incrementalcompiler.version.properties is non-hermetic and I am thinking whether we should remove the logic at Zinc side too.

The use site seems to be here https://github.com/sbt/sbt/blob/v1.10.3/zinc-lm-integration/src/main/scala/sbt/internal/inc/ZincComponentManager.scala#L121, so I guess we're using that as a cache key for compiler bridge products?

Thanks for the info!

This is out of the scope of this PR but I am thinking whether the cache key (stampedVersion) should just include version instead of both version and timestamp to make the cache hermetic. Maybe back in the old days when Zinc was part of sbt repo, timestamp is needed to invalidate locally built zinc product. But now they are in separate repo and the use case for timestamp is gone.

Maybe back in the old days when Zinc was part of sbt repo, timestamp is needed to invalidate locally built zinc product.

Yea. That sounds like a plausible hypothesis. Maybe when the version is non-snapshot, only the versions should be used, and otherwise use sha256 of something?

I am actually thinking if we can do something easier. We can just always invalidate if the version ends with "SNAPSHOT". As even for sbt maintainers, there's very few situation we use a snapshot Zinc version in sbt repo (at least I never had to do it).