Favor -SNAPSHOT version when publishing Mill locally

[alexarchambault]

This makes the millVersion task return a more stable value during local development (the version on CI doesn't change on the other hand). That value ends up in BuildInfo files, so having it not change prevents it trigerring re-compilations.

Without this change, adding files to the staging area, committing things, or sometimes just creating new files, was changing the millVersion, and as a consequence trigerring a re-compilation of many things.

[alexarchambault]

Don't know if you rely locally on the more detailed versions. They're really a loss of time for me.

[lihaoyi]

@lefou could you help take a look at this? All this code is interacting with the vcs version and you probably have thought about it more than I have

[lefou]

Sure, we can change the configuration. mill-vcs-version should support many use-cases. The question is, what we want? Should local modifations to the git hash result in a changed version at all? Currently, we let the detailed change reflect in the version via a hashed value, resulting in ever changing versions. @lihaoyi already worked around this by don't requiring jars but classes-paths as dependencies.

In a work project, we instead use a static -DIRTY suffix. That way, we always detect that a build might not reflect the exact git hash, but once we are in that state, the version is stable. Here is the config for that:

VcsVersion.vcsState().format(dirtyHashDigits = 0)

In the same project, we also have a local override.

def staticVersion: T[Option[String]] = T {
    val file = staticVersionFile().path
    if (os.exists(file)) {
      val version = Option(os.read(file).trim()).filter(_.nonEmpty)
      T.log.info(s"Using static version `${version}` from file: ${file}")
      version
    } else None
  }

  def version: T[String] = T {
    val git = VcsVersion.vcsState().format(dirtyHashDigits = 0, commitCountPad = 4, countSep = "-")
    staticVersion().getOrElse(git)
  }

[lihaoyi]

I'd be ok with publishLocal using stable {stable-tag}-SNAPSHOT versions. The only thing you lose is to have multiple local publishes that you can swap between, which isn't something I've ever done: I always only have one local publish that I'm using at any point in time.

I do use installLocalCache quite a lot for testing things out in scenarios where I don't want dist.run, e.g. I don't want to have a wrapper Mill process running along with the child Mill process to confuse me. dist.launcher is also an alternative that provides that, but currently there's a bit of boilerplate around using it (see readme.md). Maybe if we smoothened out the workflow for using dist.launcher, we could rely on that more heavily for more scenarios except when we really-truly need to exercise the assembly-publish-download-jar code paths.

But For this PR that seems like it will speed up installLocalCache, I'm fine with proceeding

[lefou]

I'd be ok with publishLocal using stable {stable-tag}-SNAPSHOT versions. The only thing you lose is to have multiple local publishes that you can swap between, which isn't something I've ever done: I always only have one local publish that I'm using at any point in time.

The pattern I was proposing is {stable-tag}-{commit-count-since}-{commit-hash}-SNAPSHOT. It will invalidate once you commit somthing, but as long as you just publish local edits, you won't see unnecessary rebuilds.

[alexarchambault]

I tend to create small commits and rebase a lot during development (to make sense of the changes, even though I only push incremental "fixup" commits now 😅), so {stable-tag}-{commit-count-since}-{commit-hash}-SNAPSHOT doesn't really help, only things like {stable-tag}-SNAPSHOT do.

[lefou]

@alexarchambault What about overriding the version with the content of some optional file or env var? I already posted it above.

[alexarchambault]

@lefou Sorry, I missed that. That would work too, yes.

[lihaoyi]

This is now moot since #4126 makes the repo use SNAPSHOT for everything unless the MILL_STABLE_VERSION environment variable is passed