Publish CLI as 0.3.0

[philpax]

We're seeing some confusion over the CLI being 0.2.3 but pulling down Ambient 0.3.0. I'd suggest aligning their versions.

[FredrikNoren]

@philpax Hm I don't think that's a good idea; they are different things so it makes sense that they have different versions. Version x of the cli can always download and run y of the runtime, so the versions are never really aligned.

[philpax]

I think this will end up being a point of confusion going forward as the version manager has the same name as the runtime ("ambient") - Rustup avoids this by getting out of the way and being clearly being separate from Cargo/Rust/Clippy etc.

I'd suggest we align the most significant number (i.e. 0.3 for version manager + runtime, but they have separate patch versions) or we rename the CLI to make it clearer that it's a separate entity.

[FredrikNoren]

Hm yeah I hear you. I don't think matching the versions make sense for the reason above (if I cargo install ambient@0.3 and run and I still get ambient v0.4 because that's what the project is, or my default version is, it just feels weird). We could rename the runtime to ambient_runtime? Having the cli named ambient I think is fine, firebase does the same, and dioxus did before (until she shortened it to dx).

[philpax]

I think those are different, because they aren't managing applications that share the same name. With Firebase and Dioxus, you're not version-managing an application - you're interacting with a platform or with a library.

If we say "Ambient 0.7 is now out" and a new user runs cargo install ambient and sees ambient@0.3.3, they're going to be confused. I think rustup is the closest analogy here - it gets out of the way until you need to set something, but otherwise, cargo/rustc all work "as expected" for the project you're in.

My preference would be to rename the CLI to ambientup or ambientvm or something, and then have it create an ambient executable that proxies to the relevant installation, as rustup does with its executables. That way, you still get the same experience of ambient-for-your-project, but the line between runtime and runtime-installer is much clearer and less confusing to users. (Maybe also move the runtime-management commands to ambientup, but that's a matter of taste)