A bit of pointers here: installer script we use to install wasp is here, in its own repo: https://github.com/wasp-lang/get-wasp .

Some progress has been made on this front, so let's recap what we have and what we want!

We upgraded installer script to enable installation of a specific Wasp version -> you can specify it with -v 1.2.3. It is also smart in a way that it installs different versions next to each other, and if you try to install version that is already on the disk, it will just use it instead of downloading it.
A bit of context: our installation works in such way that wasp is installed on user's machine under some-wasp-dir/1.2.3/ -> there is bin there and some data. So we have such dir for every version. But then, we also have a small wasp script in bin which actually points to the version of Wasp that is currently active.

What all this means is that with installer script, already now we can easily switch wasp versions as we need -> you type curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s -- -v 1.2.3 and you system will use wasp 1.2.3 from that moment, downloading it first if not already on the disk.

So, users can actually easily switch versions now, which is good, because we also added it so that projects specify which Wasp version they need.

Let's now revisit what we want to have in general regarding requirements:

1. We want to enable users to easily switch wasp versions as needed, so they can choose the correct version for the project they are working on, or for the new project they are starting.
2. We want to enables users to easily learn about new versions of wasp and perform upgrade.

I think that is about it. Some examples of stuff like this are ghcup and rustup, or nvm to some degree, ... -> there are different solutions.

In our case, the requirement (1) is already achievable with the installer script as it is now. But it is not so easy to use, you need to put in that long command each time, it is hard to remember it, and also to even figure out that you can use it that way (we do have error message that tells you to use it if you are using wrong version of Wasp for the project though, so that helps).
And for requirement (2) we don't really have anything right now in place.

Some ideas how to approach this:

1. Have wasp upgrade command, that when run, tells you if there is a newer version, and suggest to perform the upgrade for you. It might be as smart as to let you know about newest braking change, and newest non-breaking change, and let you choose.
   It is kind of clear to me that this is interesting for non-breaking change, because upgrading is no brainer, but it is a bit less clear for breaking change -> in that case I will also want to upgrade my whole project to newer wasp, right? So will this command also do that? Hm.
   Finally, what about switching to older version, because I checked out a project that needs it? Do we do wasp upgrade -v 1.2.3 and then it actually downgrades if needed? A bit weird semantics then.
2. wasp version use 1.2.3 command, that acts like nvm -> it switches wasp to that version, while installing if needed. It would just be calling installer.sh in the background which is great. You could use this to downgrade, upgrade, pick the version needed for the current project, ... . Maybe if you don't specify the version, it uses the one of the current project, if there is one?
3. Wasp could switch version for you, based on the project you are running it in, automatically. But what happens when we want to start using new project, how do I pick version then if I am not in a project?

Maybe best hybrid is something between wasp version use and wasp upgrade -> having both?
wasp upgrade is nice for visibility of upgrading and it does for you the work of figuring out which version to use / upgrade to. But it feels weird downgrading through it.
wasp version use feels great for just switching version here and there, but it is harder to discover I think, and I imagine you would need to know which version you want to switch to.

So we have a couple of use cases / requirements, and a couple of methods, and we could use mix of these methods, so this is what it makes it a bit hard to decide what to do!

Any suggestions / ideas?

I think there are two points we might bring at this point:

1. Version management
2. Project-based compatibility

(1) If I follow your reasoning for version use ..., we have something like rbenv which allows setting ruby version globally, locally (per project), download latest version (install -l), etc.

But I think it's the role of a package manager.

(2) If we think about compatibility, we might look for a mechanism used in rust which consists of setting rust's version in the project's configuration file.

Either we keep the issue as it, which is simple, or we'll have to (re-)design to make it version-aware.

If I have a last suggestion to make: version verb rarely have parameters, but I've never seen one doing destructive operation, finding another name would be better.

Really good recap and analysis, @Martinsos. And kudos for adding the version installer script and being able to use the latest install, that is already really nice!

I think you captured all the possible options I can think of for how it may work. I tend to like (2) since I like how I can do this with nvm. If we add a wasp version I think we may be able to potentially solve all problems:

• We can automatically check if there is a newer version of wasp available than the latest installed every time they execute any wasp version command, so they implicitly always get the checks. This comes at the cost of a network trip, but maybe worth it?
• We can have some useful aliases to do things like wasp version use latest that will download the latest, or wasp version use project that will install the lowest/highest compatible version based on what is specified in the .wasp file.
• We could potentially switch the version for them as well, and we could have a wasp version set default or something where they can specify a global default to use when not in a project.

Overall, I think we could get a lot of mileage out of wasp version if we thought through all the cases we wanted to cover. Perhaps it could even have the intelligence that wasp upgrade if we had a wasp version upgrade that listed breaking changes between the current project and the specified version.

@blackheaven you do make a good point about the implied semantics of version. Indeed, perhaps a different term is warranted.

Thanks @blackheaven and @shayneczyzewski -> all makes sense to me, I think what remains to figure out is if we will be using version for this or not, since it is true that it would be a bit unexpected semantic, although it does make sense on the other hand. Once we make a decision there, I think we can go for some relatively simple first version of (2) solution.

I will let this be for a moment though, since what we have right now already works, even if not super elegant, so we can come back to this in the future when we have enough time.

@Zeko369 said he would love to have wasp upgrade.