I’ve never seen a release candidate with so many issues and bugs. I know 2019.3 was a huge undertaking for Unity so I suggest not to rush the release. Take the time to make sure 2019.3 is not only stable but visually usable. Right now the new UI has way too many issues.
Cheers,
I’d suggest targeting 2019.4 LTS for your project.
But 2019.4 comes in 4 months or so. That’s almost half a year.
Unity postponed the 2019.3 release already, as announced last year via their blog. I guess, they’re doing pretty much what you’re asking for already:
BTW, there is another thread that’s discussing that topic too:
… might be worth to leave your thoughts there, so we don’t have two threads that discuss basically the same thing 
Yes, and that delay involves releasing this month instead of last year. Can you (or anyone else here) really say that just over three weeks is enough time?
Now that the Unity blog said that they do not recommend people switching to 2019.3 until spring (the LTS release),
would it be possible to keep this forum (2019.3 Beta) open until that time?
It would provide continuity to the 2019.3 issue tracking in the forum.
I agree. I think it’s better to take the time needed to deliver a stable update.
My instinct says this is part of a process to convince stakeholders that unity is at a certain level of development and take unity public.
Software development is extremely complex, and with such a giant user base there are too many factors. I don’t think it’s realistic to predict when an upgrade will be ready.
I’d even vote for a return to version numbers. Using years like 2019,2020 etc backs unity into a corner, forcing them to deliver a specific update before a specific time. This doesn’t allow for any unknowns in the development process and is probably more a marketing thing.
It can’t be easy for people working at unity to meet these deadlines. I worry that they may feel under pressure as well.
As always things are not black and white and I think it really depends on your project. I for example use 2019.3 since all the betas in a very ambitious project and had lots of smaller issues but with f04 I have to say I can really work. No single editor crash since then. I develop for Quest in URP and except for the NavComponents not working all I need is there and fine so far. Also the editor behaves well in my eyes. On the other side, I have a beast of a machine here.
It’s not about specs, it’s about use cases existing outside of your own.
I am in agreement that it is ill-advised to consider 2019.3 for anything more than hobby games.
Unity has been petal-to-the-metal for new features and DOTS since 2018.1 it seems and there is a lot of accumulated development debt.
That said, I’m very hopeful that DOTS/Addressables/SRP will be really actually not-kidding truly production-ready in 2019.4. If they are, I’ll probably be using 2019.4 for a very long time. If not, we’re in for another year of doing free debugging work for Unity.
I’ve got a fork of my current project using Addressables and I’m still trying to debate if I want to switch to it from my AssetBundle version. When they work they’re an absolute game changer, but yeah, there’s a lot of areas where they just aren’t mature enough for anything but hobby stuff. I don’t know if I can trust them in development, and that’s been my problem with the last few Unity releases: I don’t know if I can trust the engine I work in.
I would say NO. I am just working on a demo version of my game, thinking that 2019.3 and addressable will not be that buggy so I can at least build a working demo for demonstration. but NO, they are not.
My current needs are pretty low-power. I’m mostly testing them because they do still have pretty big streaming performance gains over AssetBundles and I’m trying to make my project have no load times past startup.
But yeah, they’re kind of a mess, even in 2019.2.
IMO the new UI really ought to have been delayed to 2020.1. But I suppose it’s too late for that.
All three known issues for the latest 2017.4 release say they have been fixed in other versions. One says it was fixed in Unity 5.5.x. Another says it was fixed in 2017.3. And the other says it was fixed in 2018.4.10 last October.
How these issues have been supposedly fixed for so long yet have not made it in the 2017 LTS release is a scary microcosm of the problems we’re seeing with 2019.3. I’d suggest targeting 2018.4 or 2017.4 for your project. How many years will it take for all the current known issues with 2019.3 to be fixed?
I’ve said this in another forum post, but my current idea of how Unity does testing is: 90% Unit testing, 10% actual Unity users trying to work with the software.
There are some bugs which are so obvious if any actual QA tester would have opened and worked with the editor…
I read some post from Unity dev who works on Unit tests and he said that amount of work is significantly increased after the Package Manager introduction. It’s hard to cover it all and the amount of tests increased a lot.
But I think 90:10 split is not a bad thing. Automated tests will always cover most of the codebase, it’s one of their purposes.
Unit tests are only as good as the one who writes them… And if it’s the programmer of the code to test himself, he might know how his code reacts and unintentionally could write unit tests that do not cover all cases. So, obviously, to me Unit tests are additional tests and should not be the main QA strategy…
Interestingly enough, 2019.3 has been the most stable build of unity I’ve used since 2017, crash wise. That is, if you ignore all of the UI bugs. For years I’ve been getting endless editor crashing, and it’s almost completely stopped now.
Of course, it sounds like I’m one of the lucky few.
I think unity has been pushing for so many features so fast that they’ve accelerated to the point of not being able to clean up their messes. I blame the going public thing, but obviously that’s just a pure guess. I agree that having dated versions is a good idea on paper, but clearly not in practice. Software doesn’t get stable until it gets stable. Also, what’s the point of dated versions when features constantly get pushed back further and further. Might as well do what everyone else does, and just have… version numbers. The PR surrounding dated versions is amazing until you’re late, then it comes back to bite you, in both the PR sense and the actual software sense.
Then again, what do I know. I know nothing of corporate software management nor marketing.
Unity’s probably going to go public at some point so it does matter they have a big feature set and a great market position. It helps that these benefits do eventually reach users.
The best way to work with Unity is to only look at the LTS releases and call those done.