Would sure be nice if Unity Hub CLI could install versions that aren't the latest patch

For example, if I execute:

"Unity Hub.exe" -- --headless install -v 2018.4.5f1 -m android windows

(at this time, 2018.4.6f1 is the latest 2018.4 patch), then nothing happens.

However, executing

"Unity Hub.exe" -- --headless install -v 2019.1.14f1 -m android windows

(at this time, 2019.1.14f1 is the latest 2019.1 patch), then it does get installed.

(well, I have to manually click through the UAC, and the Unity Hub Window is created/foregrounded, so it's not exactly headless at all, but I'm sure you're aware of that).

I want to be able to install not-exactly-the-latest versions of patches, because I don't want to force anyone to update at an inconvenient time.

 

OK, maybe it's just inconsistent...

"Unity Hub.exe" -- --headless install -v 2019.2.0f1 -m android windows

doesn't seem to do anything, even though 2019.2.0f1 shows up in

"Unity Hub.exe" -- --headless editors

Oh! The previous version hadn't finished installing. I got that message many minutes later.

An error message that it was busy doing something else would be nice, but even better:

The whole "run the command but it's backgrounded and you don't know when it's finished" paradigm on the Command Line is not one I'm used to. Hopefully this is an artifact of it being in preview, and Unity plans on changing it to not exit before the command is done, ... right?

 

This seems like an oversight. You have the information about what changeset matches what version, so the hub should be able to figure out without us having to provide it.

The changeset is nice if we need to specify some non-public version of the editor (console version or whatever), but by default writing "install 2018.4.5f1" should just do that.



I know that you're really stubborn about the Hub not including all the versions we need in the GUI, even though we need them there. Like, you're fighting hard to have your software be bad for some strange PR/whatever reason. But the CLI isn't visible in the GUI, so you could decide to have the CLI not be bad.
Food for thought.

 

@Baste

It’s not an oversight but unfortunately was a limitation we had to accept for this first implementation of the Hub CLI. What you described as install <version> is what we want to implement but requires more work on our backend.

As far as the UI goes, it’s been mentioned several times before, but just to re-iterate it’s simply about listing the latest “supported” versions of Unity.

Thanks,
Daniel

 

@DanielTG @AbrahamDUnity

Adding support for local files would also be a great update.
I mean pointing to the complete Unity Editor Installer File and Modules like Android to avoid downloading 300 times the same files in our school.

 

One year later... Same problems...

 

Still the same problem...

 

Where is that next iteration? Almost 2 years...

 

+1

 

Guys, hi! Still in work?

 

bump

 

Another perfect example of abandoning a tool that could actually be useful. It doesn't make any sense to have to provide the changeset to install a non-latest unity version. Completely defeats the purpose of abstracting the whole process of installed unity in a single call. Not everyone is always working on the latest unity version. Is this actually still being worked on? It's been 3 years since any official response.