release Compiler v1.12.0 (and discussion on how to use it)

[aviatesk]

For external packages like Cthulhu that use the Compiler.jl stdlib, it's quite a hassle to manage all three types of compatibility: between the external package, the Julia runtime, and Compiler.jl.

I'm thinking instead of handling these compatibility issues by some complex version engineering for Compiler.jl, we should keep its use supplementary. External AbstractInterpreter packages should primarily use Base.Compiler, while managing compatibility with the Julia runtime and Base.Compiler. This would bring us back to the previous situation, but it seems better in terms of compatibility management.

On the other hand, using the Compiler.jl stdlib allows for easy switching of the Compiler implementation, which should be an optional benefit. This is especially useful when developing the Compiler itself, where it's common to do pkg> dev /path/to/Compiler. In such cases, the implementation of the Compiler.jl stdlib should be used instead of Base.Compiler.
As a mechanism to switch the Compiler implementation used by external AbstractInterpreter packages, using package extensions might be the simplest approach. As shown in
this example PR, we can switch the Compiler implementation when using Compiler is called¹, and still precompile the usual code. However, to list Compiler.jl in [extensions], it needs a version. To this end, I propose releasing Compiler.jl versions in line with the Julia runtime versions, following other Julia standard libraries. But we would only do minor version releases, not patch releases, which are harder to define. Specifically, we could release a corresponding version of Compiler.jl when a release branch is cut. After that, we wouldn't manage patch versions, and as long as pkg> dev /path/to/Compiler works, this simple versioning should suffice.
Alternatively, we could register a single version 1.0.0 of Compiler.jl with a dummy implementation, letting the external package determine if the implementation is real (developed) or dummy, but this seems more hacky than using package extensions.

Footnotes

1. Also, I'm aware of another issue: when using the Compiler.jl
   stdlib, you need to run InteractiveUtils.@activate Compiler first,
   or else some reflection utilities won't work (for example,
   Base._which(tt; method_table=Compiler.method_table(myinterp))).
   I think this problem can be solved by adding
   InteractiveUtils.@activate in the __init__ function of the package
   extension code, but I'm not sure if this is a safe solution. It might
   be better to set up a callback that only gets called when
   InteractiveUtils.@activate is executed? ↩