Tobias Roeser
Tobias Roeser
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...
> 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...
@alexarchambault What about overriding the version with the content of some optional file or env var? I already posted it above.
`Agg` ensured (silently) that there were no duplicate entries. When removing it, we should also revise other places like `T.sources`/`Task.Sources` or `ivyDeps` whether they should de-duplicate their inputs to avoid...
Mill has no dedicated Java 23 test suite. Our full CI doesn't succeed on Java 23 due to some tests exercising older Scala versions that are known to be incompatible...
I just checked, I can build Mill's own code base (`0.11.x` branch) with Mill `0.11.8` on Java 23 too. I couldn't check older versions due to feature requirements in that...
@lihaoyi Do you mean to decide inside the input task whether the heavy work needs to be done and do it conditionally? This might be doable when we make `Input`s...
The charm of the current `PathRef` validation is, that it only runs if the task was cached before. It just throws a specific exception when loading the cached result from...
The `persistent` solution still has to handle the persistent of the result to have it available for the validation step. Although Mill knows all cached values, we can't access them...