0.12.10 and next steps towards Mill 1.0.0

[lihaoyi]

0.12.10 was just released and contains the non-breaking changes that have been landing in main. Please try it out if you are able!

The major changes that we've wanted to get into 0.13.x have mostly landed:

• build.mill files compiled by Scala 3 #3369
• Remove Agg in favor of Seq #4525
• [WIP] Make Evaluator only available to Task.Command(exclusive = true) #3717
• Integrate os.Checker to sandbox filesystem IO #4635)
• Restrict sources and inputs to not accept upstream tasks #4524
• Replace import $file syntax with flat package namespacing #4462
• Clean up Discover macro and codegen #4461
• Renames, privatizations, and other API cleanups (too many to list)

Not everything has landed, and there will be continued work, but the bulk of breaking 1.0.0 changes are in.

Approximate Timeline of Next Steps:

• Early April: Re-bootstrap Mill's own codebase on top of the 1.0.0 branch.
• April: continue work on Mill, resolve any issues that get surfaced by the re-bootstrapping
• Early May: cut the first 1.0.0-RC1
• May: Re-bootstrap rest of com-lihaoyi projects onto Mill 1.0.0, encourage testing by broader community
• Late-May: Cut 1.0.0 final

[lihaoyi]

Probably the last major change I want to get into 0.13.0 is #2703. This would set Mill on a much better technical foundation with cleaner classpaths for the runner, user code, and plugins. It will require an overhaul of the BSP/GenIdea codebases, which will be a lot of work, but probably can get that done by the May target date for RC1

[lefou]

What I really like into 0.13, but which isn't that well discussed is a better concept for various test tasks. What I really envision is a way where all test runners share some state, so a testCached after a successful testForked doesn't need to run at all. I could imagine we could use a worker to keep/access that state.

[lihaoyi]

I'm planning on naming the 0.13.x series to 1.0.0. According to SemVer,

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

So I think naming it 1.0.0 is already overdue. This doesn't stop us from making breaking changes in future, it just means that the next breaking versions will be 2.0.0, 3.0.0, etc. which will better align with people's expectations for what the different version bumps mean

[rgwilton]

I think labelling it as 1.0.0 is a great idea, since it gives the industry more confidence in the stability of the tooling and the project overall.