Fast Update Button of the same Vr.?

A fast direct update button?

as for example:

  • U19.1f0 to U19.1f1
  • or U18.4.20f to U18.4.21f

You should post this in the feedback thread: Unity Hub v2.0.0-beta versions feedback thread :slight_smile:

Is it a problem if there is a fast update button? I don’t have it for that particular version by the way.

I think he wants one. If Unity implements this, it will bring havoc. I really hope Unity will pass this one. Updating Unity versions should not taken lightly. Deleting an old version and update to a new one should be complex (download new deliberately, uninstall old deliberately) thing because opening a project in a different version can be destructive.

2 Likes

In my world its pretty dumb to adjust the environment after the 10 dumbest procent in the team. If we did that we couldn’t use things like DI because they would think it hid dependencies (I have actually heard this one for real on projects i’ve been on).

Same applies here. Though they could off course make it safe by for example warning the crap out of users that are detected not to use versioning.

I was thinking for smaller updates of the same final version
as for example:

  • U19.1f0 to U19.1f1
  • or U18.4.20f to U18.4.21f

You don’t update Unity under a project like that. Does not matter if it’s a minor version or not. The chance to break your project is lower though, but it’s not zero.
Right now you have ~4 clicks to think through what you’re doing, you would reduce it to 1. Which means more people would blindly change Unity versions under their projects (Unity is big enough to start to think in statistics), which means more support inquires and forum posts about “Unity killed my project” and stuff. → Havoc

I’m not sure it worth to do you would save 1 or 2 clicks. It’s not that big improvement for the price. (From Unity’s point of view)

Yeah. But you wouldn’t think the same when you actually work on consumer product and you would make a plan for customers. I mean if you want to be somewhat accepted among your customers. If you want customers, you know…

There is no difference if you make a product for professionals or consumers, in this regard.

I’ve been advocating this idea for some time now. Obviously it needs to be clear that updating a project is risky, but it’s already something users are facing (especially when using Unity’s embedded launcher). Based on install management software good practices I believe the Hub should keep older versions under the hood and still open projects with the version they were created in.

Of course at this point this feature requires a lot of thought and planning. I can’t say it will come in the near future but I’ll definitely continue to push for a safe and convenient way of upgrading major Unity versions.

Cheers,

2 Likes

What are you on about? Please don’t leave 2,3 gigs of data on our hard drive under the hood.

I don’t even… Do you have any respect at all for the people who use your product? Unity’s not the only thing we need hard drive space for! Unity’s not the only thing we run on our computers!

The Hub’s job is to manage Unity installs and launch Unity projects. You’re talking about obfuscating which Unity installs we have, and what version projects are launched in. That’s not the correct thing to do! That’s exactly the opposite of what the Hub should do!

Or am I reading you wrong?

I’m not opposed to a button users can click to replace the current version with a new one, if that’s what they want. If somebody’s planning on staying on the latest tech release, that’s completely valid, and having a button that simply swaps the current version with a new one would help with that.
But I can’t imagine that people that want to only have the latest version visible would want to actually have all the versions they’ve had, just hidden. I can’t imagine that those people would want their project to open in an older version after they updated the single version they have.

Hi @Baste ,

As I said this feature requires a lot of thought and consideration. We have to accommodate many preferences and workflows. I like to prioritize safety and avoid wasting bandwidth which is why I mentioned keeping older versions after updating. Of course I didn’t suggest keeping all editors in a hidden folder for all eternity. I hope this clarifies my position.

Cheers,