Tobias Roeser

That's a good point. `Target{..}` or `Target.command{..}` isn't that worse than `Task{..}` or `Task.command{..}`. And since `T` is just an alias to `Target`, users can already write `Target{..}` instead of...

I agree, that mentally `T` stands for `Task`. I really wish all those `apply`-like methods would be defined in `Task` and not `Target`, so I'm in the same boat already....

What always bugged me is the fact that a `T` produces a `T` but a `T.worker` produces a `Worker`. From a consistency standpoint, we want to produce either a `T.worker`...

The existing `T.command` / `Command[R]` always played a special role, since it's some factory for tasks, based on their parameters. Its "constructor" accepts a task and mentally, it's more some...

This is not an issue for `0.11.11` and `0.11.12`. We could just remove documentation for `0.10.10`.

Could be that the intro page `Java_Intro_to_Mill` does not exists in `0.11.10` since it was only added in `0.11.11`. But switching over to `0.10.x` works too, although the intro page...

As a work around, you can run `mill shutdown` to stop the server, which will also stop all workers.

> how bad it is to build mill's plugin with sbt? Mill plugins are just ordinary Scala libraries. You should keep the Mill binary version in the artifact name, as...

`prepareOffline` comes from `mill.scalalib.OfflineSupportModule`. It is inherited by all `JavaModule`s and `PublishModule`s. `dist` should have a `prepareOffline` command as it is defined like this: https://github.com/com-lihaoyi/mill/blob/9b5e8194054184f167741a3c1f7d4870750c537c/dist/package.mill#L64 and `InstallModule` is a `PublishModule`:...

Have you also tried to use the `--all` flag? ```console > mill dist.prepareOffline --all > #or > mill __.prepareOffline --all ```