[Request] Patch releases and earlier unity versions

Hello there,

just got a brand new system and thought I might give the Hub a spin. I was quite disappointed to see that I can only download Unity 2017.1.3f1, 2017.2.1f1 and 2017.30f3. I normally always use patch releases, so for powerusers that might be interesting. I also do use unity 5.6 as well, so I would wish to be able to download those as well.

 

I second the request to include patch releases. I'm much more likely to use a patch release than a beta release, and I see the hub does include beta releases.

 

I hope you will reconsider the inclusion of patch releases; IMHO the appeal of the hub is the option to efortlessly update Unity, without having to download the installer manually and go through the installation process.

 

I do understand that I can add releases, which I have done by now, but as @pavelkouril mentioned, it is a thing of convenience, which would make the hub more valuable for me. You could add a tab like with beta releases for patch releases.

 

Managing all of the Unity that exists on the web should be the meaning of the Hub.
The user who is using patch release should be the main user of the Unity hub. I can't figure out why I don't support the patch release.


+1

 

I think I work as much on patch releases as non-patch releases, so not having patch releases available will be a huge drawback. I could download them manually and then add them, but that's really inconvenient. Maybe hide them behind a checkbox?

Also, is there any chance to get access to downloading the not publicly available platform-specific builds if we're logged in as a user registered for that platform? Unless that's already in and I just haven't checked.

 

What about release notes for the official releases/betas in the Hub?

 

I do understand how Unity is handling this and I would agree if... I can also say I successfully use normal releases without any issues. Because since 5.6 I had never a first release without issues. From 5.6 up to 2017.2 the versions were plagued by VR issues or videoplayer bugs. 2017.2 up to now I still encounter weird bugs as in the most recent one the ctrl+z after a slider has changed it's value.

So in this cause I understand unity wants only normal releases to be included but in reality I always use patches to fix things I encounter. Of the 5 installations I have, 3 are patch versions. Just to give feedback on this statement.

 

As one of the intentional patch-grabbers who sets up lots of new dev machines and maintains all the docs around it for our team, I'd prefer there's a path to get them in hub still. You could always add an additional disclaimer to the path-install flow in the hub.

Of course, having the "1-click-install-via-the-hub" is a nice feature too, but I still don't think that replaces just including it in the hub itself.

Edit: for reference, the last two releases we've used in our project (since August) have been patch releases. The first being the security patch -- a good example case for you guys, and the second being a patch we targeted intentionally.

 

In my opinion the Hub should serve as a centralized management console for ALL Unity installations, including Patch releases.
I do not want to navigate to a web page just to click a button that will trigger an installation in the Hub. It should all be done in one place and the Hub is the perfect tool to manage all that.
I think you guys should seriously reconsider integrating patch releases into the Hub. You can always add a warning to users that Patch releases are intended only for users who are affected by a bug.

I think the Hub should completely replace the current Unity MSI/DMG installer. That means, we should never need to go to the Unity website to download an installer file. Everything can be managed via the Hub. That would be the ideal tool for me (similar to the UE4 launcher).

Thanks,

 

Please reconsider keeping the patch versions in the hub. I understand what you're saying, but wouldn't that QA argument also hold for beta releases? I'd strongly prefer to manage everything from the hub, and I'm getting the sense that I'm not the only one.

That said - so happy to have this tool. Thanks, guys!

 

Good luck getting all the platform holders to agree on a single way of doing that!

My general experience is that patch releases often fix bugs introduced in the official release. I'm more confident in the quality of a p4 than an f3. That might be a misconception. Still, I'd love to have a checkbox for "I want ot see patch releases".

 

I understand trying to protect users from unnecessarily using patch releases, but I think the only real way to do that is to make the patch releases less necessary, i.e. keep the major versions stable and up-to-date with the latest platforms and platform requirements as possible.

Aside from that, it's not obvious to me that it's really a problem that needs solving, as long as it's clear that patch releases are not as well tested and buyer beware. Anyone who is placing a premium on stability will stick to the major releases and anyone who really needs a fix (or desperate to try one), or just likes being on the cutting edge, will try one. In the latter case, if you get bug reports you otherwise wouldn't have, that's free QA, and I don't see how it's worse than trying a beta release.

As it is, periodically I Google "unity patch release" to find the patch download page, and if there's a new patch browse the release notes to see if there's a fix that looks important, especially if it's something that might fix something I'm experiencing (which brings up another point: browsing the patch releases is like peeking into the bug databse to see the latest "what's fixed").

So even if I'm overusing patch releases, sort of hiding them doesn't really stop me from searching for and sometimes using them, it just makes it more time-consuming. And actually, my preference is to stick with the non-patch releases (especially since I do WebGL builds), but usually I feel compelled to try a patch release at some point, and once I switch to a patch release, I figure I might as well try the others, until the next major release comes along. Although maybe Unity Hub will help with this, as I may be more likely to switch from a patch release back to the previous major release as appropriate, whereas right now I just stick with the latest that I downloaded.

 

+1 on older Unity versions, when making a small amend to an older project developed in 5.6 I would rather stick to that editor version.

 

Patch releases NEEDS to be an option in Unity Hub. Even if they are hidden behind a setting checkbox like Baste said (this is for example how the Minecraft launcher handles pre-release and really old versions). You say only use them if you are "affected" by the fixes, but everyone is affected because it patches bugs from the final releases that everyone are affected by, sometimes even SECURITY bugs. If you hide it behind a checkbox, fine, inconvenient, but it works. But having patch releases it absolutely a must for me if I'm going to use Unity Hub. Patch releases are really the only versions of Unity I use besides beta. (Even if I should only be using final releases, I live on the bleeding edge, I'm literally on Firefox Nightly writing this right now!). It's not hard to add a checkbox setting and disclaimer.

 

I think there might be a slight misunderstanding on how we manage patches. We are already offering patches to official releases in the hub, like 2017.3.1f1 which is the latest collection of all the patches for 2017.3 in a fully tested version. Versions that end in pX are patches that we quickly deploy so that users that experience specific issues can updated their version to overcome their specific problem. However, from the Release Management perspective, we want our users to stick to fX versions, which have gone through the whole QA cycle and offer a better quality.
I hope this clarifies a little bit the situation?

 

We're aware. No, trust me, we really understand that. We understood that a week ago when Superpig wrote the same thing.

Look, I was writing out a diplomatic answer, but I just... man. Could you maybe, for once, trust your users to know what they want?

We know what a patch is. I know that you're not trying to be condesending, but when we go "we understand that you want us to be on fX releases, but please let us download pX releases on the hub anyway", explaining that you want us to be on fX releases again isn't helping.

We end up on pX releases sometimes for various reasons. If those are not available from the Hub, then we end up with two different ways of downloading Unity, which is really cumbersome and unneccessary.

 

I understand. I'm interested to know more when you're able to provide more detail. For what it's worth, as a Unity user, I am totally fine (and would actually prefer it) if patch versions installed in their own self-contained bucket (just like official and beta releases), rather than some kind of mini or reduced patch installation. That way, if something goes wrong or I no longer need it and want to discard down the road, I can easily nuke it from Space without any risk whatsoever to another version's (or patch's) installation.

 

Agree, simply because in general a week after any official release is out ( which i believe you are forced to push as official ) there is a patch of this official release with 50 bug fixes ( and may be 50 new ). Unity is never free of bugs enough, which is really bad and i always go and download any new patch release simply because i never know how any of the bugs influences engine behavior in previous version. So i vote for having patch releases in the HUB as well in order to download it faster .

Agree here as well. If i have to go and download any patch release ( as i mentioned many people do just to ensure some annoying bug is fixed ) from the web page why would i need the HUB as i can do for official releases as well !?

One more thing however. Is the "Analytics" enabled by default !? Many times, simple test projects are created just to prototype something and if you forget to disable the analytics you will end up having this test project in analytics page which i believe you can't remove. So it is not a good idea to have this option enabled by default ! Let the users toggle this whenever they need it !

Btw, the HUB is really great peace of software !
I am really glad you already have it done and i hope you will improve it even more as EPIC Launcher is extremely useful!

Cheers !

P.S. Plus having the software version visible and "Check for update" option would be great as well !

 

This doesn't really make sense when beta releases are shown in hub if you only want people to stick to fX versions.

Patch versions are essential to making hub useful internally, especially when we are affected by a bug and must use a patch release!

 

Jumping on the bandwagon here, but generally HoloLens and UWP users have to almost always get the latest patch releases because something didn't make it past QA.

Seconding having at least the option to show/hide patch releases in the Hub, or at minimum better QA and more stable Unity releases. I know you guys have been stressing how much you've been trying to raise the bar on that, but it's a lot to handle, props to you guys for all the hard work.

 

I'd really like to see this. Could you not just hide the patch section by default, and make them visible through the settings? Too many times I've encountered showstoppers on a new main release, so now I always use patch versions. Never had a problem.

 

No need to think for the developer which version to use it. Just let's use patches

 

Did you mean this part from the new plans blogpost:

I assume this means that the weekly patches will be in the hub once this change lands?

 

Yes! The LTS releases are listed in the Installs tab of the hub and will soon have some labels to be clearly identified as such.

 

Okay, feeling better about the fact that patch releases are going the way of the dinosaur. As long as I can get any version of Unity I need in the Hub, I'll be happy.

Thanks for all the hard work guys. Hub is pretty awesome so far.

 

Just gonna throw in my two cents: It would be great to have a way to see versions other than the latest in the Hub! I also set up a lot of computers and have multiple versions of Unity on my machine, both because of old projects that were too stable to update and because ~certain consoles~ require a very specific version of Unity to match with their dev tools.

Loving the Hub so far!!

 

Bump - this is still a valid and relevant request, please consider adding support for patch releases in Unity Hub. I get that with the Tech/LTS channels that were announced in April patches are no longer released as frequently as they once were.... but Unity still does periodically release them.

 

Hi!

Just had to help a coworker find the installer for a version of Unity, and it got me thinking of this post. The solution you propose here is not a very good one, for the simple reason that people can't find your release archive web page. It's hopelessly buried behind a maze/jungle/other metaphor of hard-to-navigate pages. Adding a button to a page people can't find won't help much.

I have yet to see someone non-technical find the downloads archive page without a major amount of frustration. I find it, because I happen to know that googling "unity download archive" gets me there. That's not something people necessarily remember.


Follow me for a journey on finding the installer for Unity 2018.1.6f1.

1: Open the hub. It's not under "official installs"
2: Open unity.com
3: Look at a bunch of pretty pictures and sales pitches. Look for anything resembling "download"
4: After a while, find an anonymous "Get Unity" button in the upper right corners
5: Get taken to a page comparing versions. Click the version you own a license for.
6: Ooops, that was a link to buy Unity, hit back
7: Scroll down. Hey, it says "Already own Plus or Pro? Download Unity". Click that.
8: There's "Download Unity 2018.2". That's the wrong thing! Hit back.
9: Look at the same page. Give up and google "Unity 2018.1.6f1".
10: Top results are the patch release notes for that page. That has two links, one that goes to store.unity.com and one that goes to the download page for the latest version of Unity.
11: Give up and ask the programmer.

At several points during this, you could have spotted a very small "Older versions of Unity" button, that's in a white-blue color that's pretty much invisible. It also something that sounds like a shortcut to getting Unity 5.x, not a version that's a month old.

In short, finding the archives is hard. Navigating through your web pages to find it is a learned skill, that takes practice. That's the biggest issue we have with updating Unity versions. You've chosen that the hub should not help with that. I still don't understand why.

 

Any update on this?

Even without offering patch and feature releases, I feel that the most common use-case for the Hub would be to manage multiple "minor point" releases, not just "major point" releases. More of us probably have as many projects distributed within major releases (say 2018.1.2 and 2018.1.6), as we do across major releases (ie: 2017.2.x and 2017.4.x). The most bizarre thing is that Unity Hub already includes this functionality, just without the ability to actually download those versions from within the Hub (which is the entire point of the Hub, no?).

That said, it's also been made obvious here and elsewhere that Unity doesn't and will never agree with us about this, and also that we'll never comprehend their bizarre justification for it. The issue isn't a technical one, and we're going to have to get over it, it seems, until Unity randomly changes their mind about it I guess.

So... I'm really just curious about the progress being made toward the "install via Unity Hub" option on the website's download archive page that was referenced earlier in this thread. I'd be satisfied with that option, even if I'd still be rolling my eyes at it. What's holding that up?

 

+1 for old releases being supported in Unity hub. We have visual studio projects and source control tools that rely on Unity being in specific locations so we can run tools like the PDB to MDB converter, YAMLmerge, etc.. Unity hub solves a lot of frustration when if comes to checking in post build commands that have a path to a specific version of Unity (before using Hub, developers had to install Unity to specific locations for our documentation, configurations, and build events to work.) Unity Hub handles this for us well, until the next version of Unity comes out making the previous version unavailable to install through the hub. Developers who need that previous version have to revert to changing the install path to match the hub path so the commands will work.

 

One more vote here about supporting old release. Sample (simple) use case : We have a project currently in 2018.2.0f1, I want a graphist to upgrade its unity to match the project, but the only official release available is 2018.2.1f1... So if i want a simple way, there is not .... Why ???? Does it means we have to always upgrade our unity version to match the unity hud one ? Or just that the hub become quickly useless every time you publish a new version.

Also if your goal is to make things simple , one feature request : allow to install the correct version of a project. For example, if I open a new project a version that i have not installed, propose to install the correct one (even if it is an old one).

 

This is a brilliant suggestion! +1 from me.

 

I have the same problem with Unity 2018.2.0f1 and 2018.2.1f1. My project is being developed and tested with 2018.2.0f1, right now there is no option to install this version with the Unity Hub, the only option is 2018.2.1f1 and that would mean updating different installs and testing many features again.

 

Hi everyone,

In a perfect scenario, I would encourage everyone working on the project to be on the latest update to benefit from increased fixes and stability but I equally understand how that isn't always feasible.

"Allow users to install the correct version of the Editor for a project" is a top priority for us to address and we are actively looking at solutions to this problem that won't require us listing every single 'update' build for an Editor release (note, we are no longer shipping patches and only 'updates' moving forward so at least the latest one will show us in the Hub). This functionality won't be available in official v1.0 release but next priority on our list.

Thanks everyone for your patience,
Daniel

 

"...and that's why we made Unity Hub." ;-P

That seems to be the disconnect here. Unity doesn't seem to agree with its users about what the value of Unity Hub is.

In my bones, I am an "upgrade immediately" type of user, but even I require this functionality. My team will upgrade every other month or so, sometimes more often, but we don't upgrade to every single minor point release because they come out so fast and that's just time out of our day we would rather spend developing our game.

And because indie teams are distributed and team members often hop on and off a project, synchronizing everyone is just needlessly difficult using the current Unity Hub. It's just feels so bizarre to have to tell the team "quick, update your Unity Editor to the latest version now, before they release an even newer version!"

Seriously, why?

The download archive page on the website can handle the UI requirements for this without being overwhelming (even while using the largest font imaginable), and Unity users are certainly savvy enough to not be confused by a separate "archive releases" section in the launcher, right?

That's the part I'm personally most confused by, is the official position that this is a UX concern. It's really not. In fact, the current behavior is an anti-pattern, and almost feels like a dark pattern.

I appreciate that Unity is constantly improving the Hub, and it looks like there will be a kind of half-solution for certain use-cases available soon (we just have to be patient), but I'm worried that they're hearing what users actually need from it and saying "no."​

 

Look, we hate installing updates. It's a drag. It takes a long time, we're not sure if any of the fixes impact our project, and waiting for the project to reimport in the new version is 15-30 minutes of not being able to work. There's no way the cost of an update in time, money and developer morale is worth the fixes and stability in that update. Sorry to say it, but your encouragement is utter nonsense. For a team of more than very few people, working with anything larger than a very small game, following that advice probably ends up directly harming the bottom line, as well as making the work day worse for the developers. So it's not "not always feasible", it's a bad idea even if it is feasible.

And you know this. You all use software other than the Hub making the Hub. Do you enjoy updating any of it? Do you believe that all the updates the different other software companies makes you install are beneficial to you?


It seems to me that the design choices being made in the hub around versioning is completely disconnected from how your end users wants to use your software, or software in general.

Which leads to:

I'm with @NobleRobot on this one, that's the wrong choice. A solution that doesn't include a listing of every single version (like what's on the download archive) is worse than a solution that includes it. By all means, put them behind an "older versions" screen. By all means skip over the pre-hub versions that doesn't support being installed from the hub. But don't bend over backwards to search for a clever way to avoid something that your end users wants.

I really don't understand why you keep insisting on this direction. To me, it feels like you're intentionally choosing to make a worse product?

 

Unfortunately Unity broke a number of things late in 2017/LTS cycle which meant being on the latest Unity version would have made our app un-shippable, so it's often un-practical.

But on an unrelated note, what happened with patch releases for 2018? Are you only doing fx releases now?

 

Yes, they announced that a while ago. There's no patch releases anymore.

 

How is it a perfect scenario ? When we are in development phase, we don't need (and don't want) every small fixes every 2 weeks.

But ... why ????? I don't see any good reason for that... just provide us a list will all releases , exactly like in the web site .... in a submenu if you want...

 

I've just come to this forum thread to express the same sentiments. I've been evaluating Unity Hub for all of three days and already I've hit a point where its become completely unusable for us. I had installed Unity 2018.2.2 and then yesterday Unity 2018.2.3 was released. I need a coworker to install 2018.2.2 because one of the console platforms do not yet support 2018.2.3, but he can't install the version we are currently restricted to and he's only given the choice to install the latest. Yes in a perfect world we could use the latest version, but instead we're going to have to ditch using Hub for now because it's just not an option at all.

 

I don't think the Hub needs to list every version of Unity. But what it needs to do is recognize when a project requires a version of Unity that isn't installed, and offer to manage the installation of that version for you so that you no longer need to worry about manually managing installations.

Something like: "This project requires Unity 2017.4.5 which is not installed on your system. Would you like to: [Install Unity 2017.4.5] or [Advanced Open]"

As it is, I currently must install every single Unity release and keep it on my system forever because I never know when I'm going to join a team which is working on a project that is locked on some version of Unity I don't have installed.

Hub should seamlessly handle installing any version of Unity (since 2017.2 or whenever the installs started supporting the Hub) if a project I try to open needs it. Then I can free up GB of space on my drives and stop worrying about keeping every single Unity version ever installed.

Hub could just list the latest LTS, Tech, and Beta releases for all I care. Just 3-5 versions listed to keep it clean and uncluttered. That's fine with me, as long as it can also handle installing any other version on demand. This would make sure people installing Unity for the first time through the Hub get the latest version, but also allow people to get the version they need should they have a project that for whatever reason is not currently running on the latest version of Unity.

 

I also vote for the inclusion of patch releases.

We often at some point of our release cycle freeze the Unity version we are going to use for the next release. If any person is late to get the correct version (you have updated the Unity) from the hub they cannot get it and might accidentally change some of the project files that might not work with the previous version that everyone else is at.

We really enjoy using the hub, as we sometimes need to go and check some of our older releases and it makes that easy.

 

Please at least make patch releases a hidden option you can enable... I know you want people to say on stable, but this is not possible. Regardless if you want us to or not. Also, the fact that you can not currently use Unity Hub for setting up local build servers, since you can not install whatever version you are on, but only the latest version of that minor version.
For us at least, upgrading Unity is a 6 month effort, so it can be done only every few years... So you can not expect everyone to be at a stable release.

 

As i understand, patch releases will not be released for post 2017.x versions !
In a matter of fact 2019 cycle should begin in a few months !
This is may be the reason Unity is not including 2017.x patches in "HUB" because 2017 will be supported for a year more only ( or something ) and i think currently it is not possible for the team to make just like this all versions of Unity to get visible in the HUB !
This would make HUB more complicated just to provide support for 2017 which was kind of "transition to the future" !

There are many projects may be that will have to be completed using Unity 2017.x!
Just an opinion on the question. I am not sure if this is the case though !

In 2018 + almost everything will be updated using the Package Manger which is really nice way of keeping the engine updated !

 

Hi everyone,

Apologies for missing out on the latest discussion till now.Your feedback is always very much appreciated.

To clarify, the perfect scenario I originally described is obviously not the day to day reality. We full understand that production generally freezes on a release, and won't update out of general safe guards. Although, if you can easily install fixes without any disruptions to your production wouldn't that not be nice? (e.g. not waiting to run into a bug, reporting it, and the being told that it's fixed in an update that was released a several cycles back.... also key is you having full confidence that our latest updates won't break API.. basically 'no disruptions' and only benefits of a more stable release)

Now back to the day to day reality until that time may come...

One of latest features in the 0.20.1 Hub release is the ability for the Hub to install an Editor release via an "installation file"

From the 0.20.1 release forum post:
- "Open the editor installation file with the hub and download and install through the hub.

This feature however is partly implemented at this point but what it will enabled us to do moving forward is two important things:

1. A link from our web archive can automatically trigger the download/install process of an Editor build via the Hub. Skipping the non-managed download/install and "locate" flow in the Hub.
2. Allow us to auto-detect the Unity version a project was created in, and prompt you the choice to download/install it if that release/update is missing on your system, directly via the Hub. This solves the bigger problem about supporting the full list of releases when a project was already created in a prior update but no longer available to download directly.

The main reason we choose not to go the full release list" approach is listing every single previous build that has been shipped for the past year is simply information overload and daunting for the majority users and on-boarding new users via the Hub is one of our key goals. Likewise, encouraging new projects/users to get the started with the latest 'update' release will only make for a better more stable experience. Which leads into the other topic, patches.

It's confirmed that patches releases are officially no more. 'Updates' moving forward will be the standard for all major/minor release that eventually will lead up to the LTS (Long Term Support) release e.g. 2017.4

An LTS release will continue to receives updates (fixes) for 2 years following it's release. We will continue to show the latest update in the Hub but equally rely on the 'installation file' file feature in case where you absolutely need the prior update.

@Vagabond_ Thanks for bringing up the Package Manager, as this definitely represents the direction we are slowly but surely moving towards for delivering features and fixes. We will still have major/minor/update release of the Editor not just for consistency but equally for features that are simply not moving over to packages. Plus each for release, we officially 'verify' a specific set of package version that have been thoroughly cross-tested against other packages (particularly when dependent systems are in play) The key different with the new package manager system is that project manifest is what determines which version of a package is installed making collaboration and staying in sync much more manageable. We have a dedicate forum on the Package Manager should anyone have specific questions.

Thank you all for reading this lengthly reply, and I hope this helps clear up a few key points as we move forward. Please keep the conversation going.

Daniel