About this whole 5.4 Beta...

Before I begin, I would like to point out that I use Unity to ship commercial games (PC) and is in progress of shipping another in a few weeks. So, this post is coming from an indie dev working with Unity almost all the time.

--

I've just seen that 5.4.0F1 was released (Release Candidate) and while I am happy that things are moving forward, I would like to raise few flags.

1. If I am not mistaken, once the build enters the RC stage, it goes through few more RC releases before public release, and from past history, this time is used to make hot fixes to make the build more stable in general - so a last minute patch up - which is good

2. My concern, and I think at this stage it should be yours as well, is that there are age old issues both "known: and "unknown" that Unity has decided to "not address". Unfortunately, some of these issues are not minor issues that cause inconvenience, but are development critical issues. And they are:

Mixed mode shadows (works sometimes but even when it does, it works in forward render)
GI baking (believe it or not they still fail at times)

Its been almost a year since Unity 5 was released (and we are in 5.4 cycle) and we these fundamental issues are present.

3. Lastly, a bunch of "Known issues" and "Will be addressed separately" issues. COME ON! I am not nagging nor whining, I am simply pointing out that we as Unity's clients, have agreed one way or another that giving sufficient time to stabilize 5.4 is the right direction to go and have also agreed to the new time line of indefinite 5.4 delay. So why is 5.4 getting released with "known issues" and issues that "will be addressed separately?" The point is to have a functional Unity Engine when it is ready, and if someone wants immediate access, we have the Beta for it. But turning a build with issues into an RC with the same old issues at bay is strange. (I would understand it if it was 5.1 or 5.2 but we are talking about 5.4, a year+ into Unity5 cycle)

Please.

Don't release 5.4 with the current issues. Take your time and take our money and get it fixed. I am not completely against the current release style (I call it the rolling development) but I honestly think Unity 5 should have at least one build that is stable and fully functional. Work up to 5.4.0b99 if you have to - it is fine, we are developers too, and we know what development is. Just don't harass yourselves into releasing a rc or full release that really is just a beta.

I hope my style of writing is not obstructing my intentions and that should anyone decides to talk further, we can talk in a constructive manner.

Thanks for reading this long post.

 

I agree, especially with the subscription change coming where owners of a Unity 5 Pro permanent license will not be able to get any future fixes to Unity 5 once the subscription changes. I feel like people who purchased a 5 Pro license should have working, mostly bug-free implementations of everything introduced in 5.0 and 5.1 at least. So having a working Standard Shader and GI, shadows, UI, SpeedTree (omg), physics, etc. I'm fine with never getting fixes for newer things like Playables, Multiplayer, VR, etc. But there needs to be a stable version of Unity 5 before it goes subscription only.

 

So.. You want 5.4 to never be released?

 

I was honestly thinking that if enough of us voiced this issue, Unity might actually make the right call. We did prevent them from that pricing cluster-f few weeks ago.

Exactly.

 

Prevent what though? The issues won't get fixed any faster. Does it matter what the version they are fixed on is called?

 

These problems have been on the table a really long time. I doubt they're interested in hanging up a release for them.

 

Well under the original pricing, pc devs's pricing went up from $75 to $125. Many people got angry and we now have unity plus which is pretty much the same for pc dev's pro at a lower cost. Check this post out if you want to find out more. This alone got 650+ replies and another 200 for the next related blog. Given that Unity blogs get 10~20 replies on average, many people were upset, and also that Unity changed their mind.

Issues won't get fixed faster, but it does matter what it is called for three reasons.
1. Divided dev power and focus: Once 5.4.0 is released (but is really a beta grade) then they will spend time fixing 5.4.0 and working on 5.4.1 then we have three builds that are not production ready (the current 5.3.5, the 5.4.0, and the next build). They were all "Betas" at one stage, and were prematurely released as "ready" - and look where we are now. I think this is catching up with Unity and they came up with a "will be addressed separately" list, which is really strange if anyone gave it a bit of thought.
2. More New Bugs: New bugs that spring up from added features is a given, and nobody blames Unity - it is part of software development. But, if new features are added while the current bugs aren't straightened out, then new bugs are introduced while the old ones are still present (patch builds fixing some of them) and it keeps going on in this cycle. Fix few bugs, add new feature, new bugs -> regular amount of bugs all the time. Think about it, we are at 5.4.0 and we are debating whether the number version does/doesn't matter while the number of bugs fixed is pages and pages long but the number of bugs seem to persist throughout. (this is partially my opinion so scratch this out if you don't agree)
3. It completely defeats the purpose of having Beta builds: The point of having beta builds is to let people know that it is a beta build. The point of having a stable build is to tell people that it is the stable bui

 

I know about the pricing.

I just don't see a lot of difference between getting a 5.4 and a "fixed" 5.4.5 or 5.5 in 6 months, vs keep getting betas and getting 5.4 in 6 months.

 

I was hoping that this thread might voice it...

Well think of it this way, imagine that 5.4.0 did actually get released when the first RC was released (couple months back...like 3 months i think) instead of having a stabilizing period, then instead 5.3.5 (which is the most stable version currently, which also makes me sad) then we would have 5.4.0 (probably not as ready as the current RC) with all the new features (CR, DX12, GPU instancing and all its new bugs and the bugs that have survived from 5.3.5). That would be a big difference and I was super glad when they delayed it.

But I see your point, and it makes sense. It also makes me sad at the same time though...

Nevertheless, I think we are getting off topic, my point is to encourage Unity to spend more time stabilizing 5.4.0

 

I agree to an extent. But this would only work IMO if there were three branches. I'd like to see the current "beta" become "alpha", and these release candidates should be for promotion to "beta". Main branch should only be "upgraded" once or twice a year to the current beta. This caters strongly to both extremes of the crowds, where the sustained engineering team simply fixes bugs and the team can backport refactoring to this code base, so that essentially both beta and stable code is running on the same core, but the stable branch simply doesn't have the larger and harder to debug experimental features. This would work well to improve both branches stability. We still allow for the most of us that will choose to use the beta daily since it'd be "stable enough" like today's main build, and also the people looking to test out the latest features in alpha.

While I'm happy with Unity's increased focus on stability, I think it's still not giving a good option for large companies would simply want to get the most stable option available.

Right now, we get a build upgraded to "stable" and then wait 6 months for it to really reach that through patch fixes. Why not just keep it as a beta build until that's been done, and shift the current beta to an alpha?

Or call it Production, Stable, Beta to encourage most people to use Stable, whereas enterprise companies can sit on the Production branch.

Because testing every 5.x.x point release for stability is both annoying and time consuming? Why doesn't Unity just call the builds what they are. Full point releases are never stable enough to use for a real project, so why call them a build of the same caliber of stability?

PS: Typing on phone; please excuse incoherency.

 

Once they release 5.4 non-beta, they will divert half the devs to start working on new features for 5.5 and the fixes for 5.4 will be much slower. Many of the fixes will be pushed only to 5.5 which means if you need one of those fixes, you either have to switch right away to the first few 5.5 betas (bound to be disastrously broken and unusable for release) or you have to wait another year until 5.5 is finally out of beta. And this is all made worse by the looming subscription deadline at which point Unity 5 is officially "over" and we move on to "Unity Without Any Version Numbers" where you have to subscribe to get fixes.

 

I don't think most users upgrade immediately as a new major version is available in most professional environments. Sure there is a good/bad mix that you get when you upgrade. You get features, and some bug fixes you had in prior version. However, the cost is often not worth retesting and determining what new has broke/changed and implementing new workarounds for bugs that will likely be fixed in a month or two. This is the same for people who work in other software dependent jobs (Autodesk, Adobe, etc.). I hear what you're saying, but I feel it's pretty rare that users are going to assume that brand new 5.X.0 version is going to be production ready immediately (even if ideally it should). Nor should users upgrade when they are in a critical section of their production.

However, the reason that this is true is when people think like you and upgrade their big complex projects so that they can tell Unity what broke... so please do upgrade your projects on the 5.4.0 release (and betas) and let them know what is broken.

 

No? They are backporting most of the fixes in 5.4 to 5.3 currently, so I don't see how the situation will dramatically change?

 

There some fixes that I wanted that I had to update to 5.4 for: the hierarchy being unstable and reordering itself was a big one but that was never backported because it needs the new hierarchy system, the one that is allegedly better for performance except when you actually change the hierarchy. And aside from just the issue of backporting, once a version is released as "stable", that means they inevitably start working on the features of the next beta, which will pull away a bunch of devs that could otherwise be fixing bugs.

 

I don't expect version updates to be completely bug-free; I expect there to be unknown bugs. But pushing a "release candidate" that contains a list of a hundred known bugs that won't be fixed is pretty obnoxious. Adobe and Autodesk do not release major updates with that many known bugs.

 

It does. And while you may not be on the same thought train to me (that Unity should spend more time on 5.4) think about this. We have bug fixes that are getting backported (like you said) from 5.4 to 5.3 - and you don't find this weird? Why isn't 5.3 getting fixed first when it is the current build? Why is the current stable build receiving patches from the prospective beta build? Shouldn't it be the other way around? And who is there to confirm that when 5.4 is released that the team will be focusing on 5.4? I get the feeling that they will be backporting from 5.5 just like now.

I am not totally against this workflow, but surely we have to admit that this is dragging on a bit longer than necessary.
Unity should converge on a build and stabilize it (hopefully 5.4) and then take the next step.

I often get the feeling that Unity users have come to accept the level of service provided by UT - and have strangely low expectations

I think you are confusing two separate things. Most users may or may not upgrade immediately which has nothing to do with what we are discussing here. We are discussing whether or not Unity should concentrate on stabilizing 5.4.0. What you are mentioning is just ill practice of few inexperienced users. I for one have a system that backs up my project to a remote server at the end of the day which means that by the end of the month, I have 30 different copies so breaking a project due to an upgrade is not even worth mentioning nor the time spent doing it (done on a separate machine, requies a few clicks here and there)

The only reason why projects don't jump to a newer build immediately is to minimize the time spent doing maintanence (like you said) but it is not because people expect the new version to be broken. That is what Beta is for. And even if for some odd reason the new build had critical issues, they get straightened out quickly. So a full release, or a major release, at least in my experience in software world, has high expectations. And that is a general thing: Major builds after many beta/experimental builds are worth looking into.

What Unity is doing right now, is not that. It is just a premature release with issues that have persisted for a long time, and obvious issues that should have been handled before the idea of Release Candidate came to anyone's mind.

 

I don't find it weird, no.

I also don't see how postponing the release of 5.4 improves the situation. 5.4 would still be a beta and 5.3 would still get backported fixes. Which is what you don't want.

Also, Unity isn't really adding a lot of features. The only "features" they add are to fix general Unity 5.x bugs and regressions.

For example, the fix to the numerous issues with lightprobes, seems to be creating a new lightprobe system from scratch. Is that a bug fix, or a feature?

 

I think we've already covered the difference that could potentially happen when 5.4 is released and also its issues related to it.

As for features DX12, VR, and GPU instancing comes to my mind - and all three not production ready as well.

It seems that you are not disturbed by the current patch cycle, but I just want to point out that your level of satisfaction or the lack there of doesn't relate to the issues (read above) that we currently have. A problem is a problem.

I am a huge advocate of Unity as well, but when things are going the way they are, we should voice it - for all of us.

But of course, we all have our own perspectives.

 

I agree with OP but I also understand Unity's hard situation right now.

For example, on of the most problematic feature of Unity 5 is new lighting system that is nothing but a joke.
Unity did a huge mistake by fully betting on Enlighten. The only fix for this would be just replacing it with something totally different and their own so they can have quick fixes without waiting for Enlighten team.

Lots of other issues are like that: old Mono runtime, legacy OpenGL.

Lets just be honest, Unity 5 is somehow fundamentally broken and if its not working for your project you just have bad luck. This is situation they cant really fix in 100 patches. The only true solution would be Unity 6 with massive code rewrite.

 

I kind of agree, but are we just reacting and responding with a very limited and personal data set!

What if Unity had a data visualisation of the current bug status (written in Unity WebGL) derived from their bug database, this information is what UT are using to decide when a Beta is ready for release.

Unity is a "massive" game engine, it supports loads of platforms and technologies and provides us with a cool way to create interactive content. I would think that there will always be bugs in it, the question is when do existing bugs drop below a critical threshold.

What if UT get the bug count down to 10% of bugs that only affect 10% of users, that's a 1% chance any user will hit those bugs. And what if only 10% of those bugs will crash Unity, that's a 0.1% chance of a fatal bug. So in theory Unity would provide a 99.9% crash free experience.

Without any insight into the bug data how can we know when Unity is ready.

And without access to source code we cannot step in and fix the bugs that affect us most.

 

I don't think putting changes into the beta build is backwards at all. It is by definition it is a less stable codebase and a test bed for changes with a group of public testers. Seems useful to me that I could push my fix to them before I push to the stable branch. Especially, if the changes are a little riskier.

If Unity tried to fix every bug in their system before release I would guess 5.4 would release in 2019. I'm sure they have thousands of bugs that are reported open and verified. To fix all of them, they would need to freeze all new platforms and advances in technology while they do nothing but bug fixing. So every release they have to do a blend of refactors, new implementations, and bug fixes. Major bugs that are a big deal to you, often don't mean much to another developer. It's a tightrope that Unity walks with every release. They already spent 3 more months getting bugs fixed for this beta. I hope it helped get them a better product than 5.2.0 or 5.3.0 were on release.

 

To answer a bit of the OP:

Issues vs. features is a fine line, and some of what you view as issues are non-trivial things to implement and take time to get right. Should those hold up the other changes that are in a good spot to releases? Should deficient graphics features hold up mobile performance improvements or audio fixes? @Ferazel has it right, Unity is big and to solve it all means freezing requirements, and that's simply not possible with OS updates arriving, 3rd party driver bugs and more.
Note that we do have a number of folk focused on the very concerns you have, but we're doing our best not to stop the trains simply for one team to complete their one piece.

We're optimistic that 5.4 is a better release for the 5.x cycle, but obviously we're still no where near perfect. It's a constant battle to improve. While there may have been steps backwards, I'm hoping you all do perceive an overall improvement, albeit one step at a time.

 

Well, to flip it around, if you think there's no difference at all between 5.4 being released and 5.4 staying in beta, then why are you arguing against it staying in beta? It would apparently be identical from your point of view, so why even care?

 

In my opinion? Yes, absolutely. You wouldn't hear Adobe releasing a new version of Photoshop where painting is broken and saying "Well should broken painting hold up fixes to the blur filter?" Or Apple releasing an iOS update where text messaging is broken and saying "Well should broken text messaging hold up performance improvements in graphics?" You shouldn't release things with core broken features, especially when you're closed source and charging money for the update. Doubly so if you're expecting to make everyone pay monthly as if it's a service.

 

On the one hand, I get that. But on the other hand, by that definition, nothing is a core feature. Anyone using Unity is only going to be using a subset of it. The people who care about mixed-mode lighting probably don't care about 2D mobile improvements. I think anything that was advertised as a big feature of Unity 5 should be considered fairly core. And Unity 5 was advertised and sold almost entirely around the promise of fancy 3D graphics, not performance improvements on mobile devices. So people who bought the update because they wanted those fancy 3D graphics are not going to be happy being told that they shouldn't have expected the graphics to actually work because mobile 2D performance fixes were deemed more important.

 

Yes. Because if a version is called beta, you know you may get yourself into some trouble.
But if it's a release candidate or even a final release, things should just work.

 

I'm not arguing against it, I'm just pointing out it won't have the effects you think it'll have.

 

And 5.4 rc is pretty stable (at the very least as stable as any other 5.x version has been)

 

I work in a team of 25 people and upgrading Unity is quite a commitment for us.

We're stuck with Unity 5.1, because it's the only build that works for us. We can't upgrade to every .dot.dot release, because having the entire team go through this is difficult and time consuming. Non-technical people sometimes need a hand. Upgrading Unity has to be planned upfront and the final switch has to be done within a short time-frame, in order that the team and build-servers are all using the same version and not too much time is wasted.

This is quite a bit of work which has to be done before pulling the switch to a newer version. And this version better be good, because rolling back is a tremendous amount of work/time.

I'm working on such upgrade for more than 6 months already, not full-time, but a few hours every week! We have an experimental build that I use to run (automated) tests with every new (beta) build to check if it would be a candidate for an upgrade. Unity 5.2 was just crashing, 5.3 was too slow, the first 15 Unity 5.4 betas or so had serious performance issues just like 5.3. Now performance is almost as good as with 5.1 again, but we run into various crashes. All of these issues are bug-reported and Unity QA is aware of them.

That's one reason why we stick to a build that we consider stable (stable with our project) and use it as long as it makes sense for us, which is to a point until a build comes out that is worth the upgrade. Worth in sense of not slower than our current version (5.1), no bugs introduced in existing systems and new features that we need for the project. Unity 5.4 would be such worthy upgrade, if these crash-bugs get fixed.

 

In UT's defence: The list of bugs fixed with patch releases and revisions is often massive. If you look at beta from beta it doesn't look like much, but from 5.3.x to 5.4 will be an evening's worth of reading material at this point.

With all of those fixes are sometimes notes of changes which had to be done (a revision can obsolete things, while a patch release must stay API-compatible), so reading all of it is necessary. Fewer surprises that way

Most of the time if I find even one improvement to something that has bugged me I'll jump on the latest. I'll take the bad with the good and just work around any changes. Fortunately I don't go near lightmapping at the moment, because that situation is FUBAR. It's also the only one that really sticks out at the moment. Most fixes relating to things I use have been pretty minor, like exposing a few new fields in physics or streamlining property names. Code-breaking, sure, but not disastrous.

The biggest problem to most are the obscure bugs, the bugs which only affect a small group of people. UT simply have to prioritise what they actually CAN fix the quickest, and dedicate less resources towards the bugs they can't even replicate. Another things we all whine about is bad design decisions (no, not just the forums), but sometimes you break things deep down when trying to fix the superficial :/

 

Well, you might be able to cast Acid Arrow, but Foresight is a level 9 spell so I don't think you can actually see the future. There's no way to know for sure what Unity will do, but given their history, pushing a beta to release has historically meant they slow working on fixes for that version and start working on the next beta, like most companies. I guess we'll have to wait and see.

 

I do understand that fixing bugs is hard, but my big issue is that the final version of Unity 5 is supposed to be in March. After that it becomes Unity 6 aka Unity Without A Version Number. Everyone who currently has a Pro license will be stuck with whatever the final version of 5 is in March unless they buy a new subscription. That final version of 5 needs to deliver on everything that was promised for 5.0, otherwise they're kinda screwing over anyone who bought a license thinking they'd be able to use those features. I feel like I've been pretty patient waiting for 5.0 features to work, but if they still don't work by the time 5 is done and they move on to 6, that's a pretty big problem and is going to make me severely doubt their ability to maintain Unity As A Service. The problem with Anything As A Service is you need to keep the service working through all updates; there's no throwing your hands up and saying "Ooops, just revert back to what we released six months ago" when you're charging people by the month.

And I know it's not the end of the world. This release is not in tooooo bad a shape. I just think that since you have a "no more fixes" deadline looming now, that bug fixes need to be higher priority.

 

Bug fixes are the higher priority, we've been devoting the majority of resources at it in fact for the past two years in fact. However, *deficiencies* are the weird, "it's a bug and it's a feature at the same time." Things like where lightmapping is, or input system and others such issues. Fixing them are often not simply a "fix" but a redo, a refactor, often fairly deep which comes with its share of consequences and time to stabilize and get the new pieces in working order. We've devoted time to these as well, and lightmapping *is* being worked on, but not at the risk of breaking existing things further. So, it's in the separate experimental stage where they have a build they're doing customer tests with. Once that gets stabilized we'll bring it back in to the fold and see how it goes. This goes for a number of the concerns, and hitting them all at once is also a risk, so we're staging them out and trying to do them more methodically, carefully, and hopefully correctly.

Will "all" this get done in time for the concerned cutoff next year? (Where all is a very ambiguous definition because each user has their own list) We're trying our best, and when that cutoff comes, we'll have to look and re-assess then to see what's the right thing to do. Then I'll expect we'll try to do the right thing after a stumble or two but all we can do is keep trying to walk forward and make things better for everyone.

 

They said they'd give a few patches after the limit, plus any really critical fixes, to all people out of contract. But what I really hope for is that the real cut-off date moves to whenever it's truly stable. For instance, if lighting is still in a shoddy state by then it would be rude to lock out the perpetual Pro owners. I think they have enough time to get at least that in shape by March though.

The input system is really overdue for a replacement. The way it works now is so incredibly clunky. I'm following the forum for updates, but I'm just running too much unstable software already to try it :/

The input system, lightmaps and the way switching platforms within a project works are all deciding factors for potential subscribers now, I think. Even crash bugs are minor compared to the frustration I currently feel over input.

 

That's because you guys are actually working correctly - one should view moving to a new version as a last resort if doing it for business.

I guess the issue tracker is up to date? Need 5.4 for fixes mostly.

 

Thanks, I appreciate your honesty. I think breaking out the new Input System to a separate module for open testing was a really good idea and I hope you guys do that sort of thing more often. I can't speak for everyone but I'm fine with that not getting done by March. But lightmapping with Enlighten was one of the most hyped and heavily advertised features that was supposed to be in 5.0. Enlighten was basically touted as the defining feature of Unity 5. If it's not working by the end of 5's life cycle, it's going to look pretty bad.

 

Wait, so Unity does not see GI and lighting as a core feature? I thought it was the very definition of Unity 5? I am really scratching my head here now as I am confused about what I've been thinking about Unity as the next gen 3D game engine...

I honestly don't mind FUBAR, it is our bread and butter as a developer. It happens regardless of whether you are making a game, a small prototype or even a massive engine like Unity. That is not the issue here (it is but we can endure this ), what I am saying is that we should spend more time stabilizing 5.4 before prematurly releasing it. One of the things that surprised me is what Alex said...

He says "some of what you view as issues are non-trivial things to implement and take time to get right" -> so spend time getting it right, and that simply the only thing that needs to be done.

and then he says "Should deficient graphics features hold up mobile performance improvements or audio fixes?" -> Release it as a patch and not as a non back porting beta feature. How does this even qualify as a reason?

and lastly "Note that we do have a number of folk focused on the very concerns you have, but we're doing our best not to stop the trains simply for one team to complete their one piece" -> Stop the train and do massive maintenance Okay, that was a joke. But seriously there is nothing gracious about advancing this way. Also, if you guys are worried about not moving forward, then release a patch, not semi abandon the current build, and turn a beta grade into a RC.

Superpig and Alex, look, I honestly want to help you guys and want to support Unity - and I have been until I saw the RC. I think we've come to a point where agreeing with you guys is now slowly hurting developers. And that is bad for the both of us. I get that there is only so much you can say in a public forum like this and that often you guys are not able to openly tell us about internal concensus - we all get it. We've released games with Unity, had people marching in on our forums and so on. In another words, we've been in your shoes one way or another. So I don't want to spend my energy the wrong way as there is just so much you can say in a public forum.

But over all this online-forum-stuff, I am raising a genuine concern that we need a rock solid build, and given that the 5.3.5 is pretty much a legacy build already (receiving some fixes...but you know what I am talking about) and we are focusing on 5.4.0, I wanted to tell you guys that 5.4.0 needs more time. I see few people getting off topic, commenting whether the builds status is good enough to be not so critical or not....but I want to get back to 5.4.0 and comment that it needs more time. I am raising that flag and is encouraging Unity to review it if possible.

And if my intentions are not clear, here is a brief summary.

I feel that Unity 5.4 is a B+ at the best, and is asking UT to revise it. UT feels 5.4 is a solid A and that it is good enough. Then I am saying after a year of Unity 5, work on 5.4 until it is a solid A+. Work on it to be a solid version that we can all rely on.

I think 5.4.0 could even be remembered as the golden build if done right and the build version that most devs choose to work on for a very long time.

 

And he is right. A massive amount of users don't want to wait around for parts they really need and stability or performance they really need... so in this case I agree with Unity's viewpoint.

Still, I found the Unity 5 mixed mode thing to entirely suck balls to the point I gave up on it long ago and changed my project so I didn't need it. I guess they need to just put a pin in that for 5.6 or something. If it comes down to it I'll just have to bake lightmaps outside of Unity and deal with things manually.

So long as stability and performance is there, I don't feel like jumping ship and I'm relatively happy (as a grump can be).

 

1. If people can't wait for features/parts, then go get beta or download and try separate modules like cinematic effects and input system
2. If people need stability/performance, then release a patch to fix it
3. Unity is doing both 1 and 2 now and have been doing so for a long time. How does this qualify as a reason to turn a beta with known issues into RC and to full release? There is no "pressing time matter" here. Unity has ways to handle both 1 and 2.

Also, I would like to point out why release notes of patches do not include the list of known issues? Please put it up at the top so that we can clearly see and work around it. It is not a matter of "let's hide it to not make us look bad", it really isn't. Please make the info accessible so that the release notes are actually worth it.

Hippocoder, I've been doing the same thing. But it is so frustrating when game design has to bend over for the sake of game engine's lack there of. I mean devs do this all the time, but when the same issue persists for this long time, I sometimes feel like just giving up on this feature

 

I feel Unity's pretty lucky to have such strong impassioned users about the quality of our product. It's humbling to know how much people carry this much concern for us, and we want to keep aiming to improve to have earned this passion. However, frankly we do have a long way to go and we're working day-in-day out in that regard. Like you game developers trying to balance the wants of all your customers, we're in the same boat trying to navigate similar waters. (Note: I've been there, crunches, deadlines and all)

What I think is still being missed is the variety of perceptions and priorities coming from the customers. I am clearly hearing the handful here, and even noting the disagreements of priorities here. I have pretty much some folk on one edge saying what's here if 5.4 is unusable, and others treating it like it's already shipped wanting development stopped and starting support (and that was a while back I'll have you know!). We're trying to balance it all and find the right point.

@jjejj87 : Thanks for you frank assessment and thoughts, it's highly appreciated and helps us shape our decisions. We are always striving to not rest on any laurels and keep pushing forward. However, if it isn't apparent, Unity has shed the idea of a perfect release with everything done. 10 years of history have shown us that it's an idealistic goal that flies in the face of reality. Most the industry (even the games themselves!) are going the incremental path, and we too are joining in that shift. We're striving to always keep improving and always get better, just incrementally.

 

Yes, it is. But the issue has been the same with other 5.x versions: They were not very reliable. But they should be. At least to an extent that you can be optimistic about not breaking your project with an update.
I have been working on about 12 different projects in the last year and only one or two of them survived an update from 5.2 to 5.3. That's just cruel.

@hippocoder
What about releasing for iOS, though? You have to use one of the latest point releases to get it working properly with the latest Xcode version. There is no way you can stick with a version forever if you have to update your app eventually.
Besides: Why wouldn’t things work that have worked before?

When it comes to new features, I understand that not everything will work perfectly right away. I understand there will be bugs that need to be fixed. But when it comes to already existing things, that stuff should actually work. You shouldn’t have to fear your project breaking when updating. That’s just an endless cycle of fixing issues while introducing new ones, causing the users of the engine to lose massive amounts of time to find workarounds to the new problems they are facing.
And I’m not even talking about some weird issues that come up in just very specific projects. Unity 5.3 has had an extraordinarily high number of critical issues that were very easy to reproduce. Why would UT ship this? Just a few days of a couple of actual humans testing the engine would find those issues.
Well, they did admit they were on the wrong track there, but I just hope they don’t actually continue like that.

@orb
I generally agree, but I have to say the issues that came with 5.3 for example haven’t been very subtle. You could probably take any project out there and experience at least crucial issues with performance.

EDIT:
Also, here is something I was thinking about:
UT might consider making the source code more accessible and actually buying bug fixes from Unity users. I am pretty sure medium (or bigger) sized teams could fix some stuff within the engine, which they probably already do? But everyone else has to work around those problems on their own or just live with those issues. However, that’s completely inefficient. When something is fixed, it should be fixed for everyone.
I shouldn’t have to spend countless hours browsing the forums for fixes and workarounds on very basic issues. Nobody should have to do that.

Also, when the Adam demo was shown, they showed an area light system developed by the guys that worked on the demo. Why doesn’t Unity include things like that in the engine? Or at least make it accessible for free as Unity Technologies’s asset on the Asset Store? Note that this is just an example of what I think could be done to improve the engine efficiently. Well, I am sure UT don’t just decide against things like that without thinking about it, but to me, it’s still a mystery.

 

a pretty big amount of unity's built in features is broken in current 5.4.f01:
- gpu profiler
- frame debugger
- custom surface shaders' normals
- terrian alpha maps (mips do not get updated)
- speed tree shaders
- instancing combined with tessellation
- shadow cascades not fading into each other
just to name the few ones i am aware of – mostly due to the fact that i am doing graphics programming.
it is a shame but in case you need some predictable results you have to stick with unity 5.1.4

 

@larsbertram1: So it's basically Unity 2D at this point :/

Performance is a whole different matter, yeah. For the most part I've been fine (flatlanders represent!), but I've seen the Android slowdowns others keep reporting from time to time. Haven't dared to use IL2CPP on Android yet. Pretty much everything I use *works*, and since I target very simple systems I've been alright with results so far. My 3D prototypes are at a level somewhere around the complexity of flat-shaded LEGO, so not exactly pushing it yet

Hell yeah! That and in-depth articles on how it was made are what I like. Give us the assets, show the process, teach us interesting tricks.

Sometimes they use experimental feature, I think. For the Adam demo they used a version with the forthcoming cut-scene director, and who knows what else it contains? The scenes looked limited enough that I don't expect a Quantic Dream-sized download though. So once the editor with those features is available I hope the project can be inspected.

 

I honestly think Unity should be transparent about known issues. I find it difficult to believe that nobody knew about the above issues. Yet, none of them made it to the list of "known bugs". Also, I'd like to suggest these two things to Unity regarding known issues:
1) Known issues are rarely ever documented(right at the bottom of the super long release note page for major releases and nothing for weekly releases. Please get the information through to us in a comprehensible manner.
2) Most of the known bugs are not even listed - why?

Thanks for the comments Alex, but if Unity is on board with the latest trend of incremental path (which is completely fine) then Unity also has to remember that having a rock solid build is the first step towards that trend. Also, incremental path does not equate build releases with poor quality. It just means that features are added over time. The two - build quality and incremental path - are independant ideas.

I keep getting the feeling that Unity feels that they are doing a good job and I hope that is not the case. Obviously this is my opinion but Unity 5 quality has been sort of mediocre at best since its release.

Lastly, I would like to make 2 easy suggestions and 1 hard suggestion to improve the current situation.

My 2 easy suggestions
1. Add a honest, transparent "Known Issues" section for every release note, with dates of when it was first found. And please don't worry about how long it is. Please approach this from an engineer's perspective and not marketting director's.
2. Add a "Maybe could be a bug but we are not 100% sure" list after the known issues so that people can feed Unity data right off that list (a link to the bug report so votes actually happen). This is going to be way more efficient in terms of collecting data to determine whether something is an actual bug or a false flag. Every time I have to deal with bug reporting, it feels like going to the national library. I can't keep track of anything other than immediate bug at hand.

My 1 hard suggestion
1. Delay 5.4 until all known issues are resolved. Keep going with 5.4 beta and do the dance that it requires - but don't release a major build with a known issue. Users still have to deal with the unknown issues anyway, so please consider this.

 

They do have the Issue Tracker. I don't think there's any way to fit that entire database into every copy of the patch notes unless you want them to take an hour to download.

 

Yup I know and have dealt with it many times, but I am just suggesting a better, or more "useful" way of delivering information. The issue tracker page has almost 1200 pages alone. I know there are filtering options and all but it is a bank of information but not a good deliverer of one.

+ I just filtered known active issues with 5.4 and 47 pages popped up. and since there are 10 issues on each page, that is about 470 (47 x 10) issues active for 5.4 - a freaking 470 known issues.

Is this real or am I looking at the wrong data? I am kind of hoping that it is.

Can someone confirm this for me? Here is the link

 

They usually do release such things for free on the asset store, it just takes quite a long time. In the case of the area lights, example code is already available at the unity labs site. It's not exactly a full featured system yet. It's easy to speculate that if the tech proves itself over time and fits with other objectives, it may very well end up build into the engine at some point.

Where I think Unity fall down on this front is that such stuff is rarely treated as a first class citizen for long. For example they released a bunch of tech assets based on things they did for the Blacksmith demo. But there is no sense that anyone from Unity maintains these assets over time, e.g. I think I've seen people complaining that the blacksmith atmospheric scattering effect stopped working long ago and I've never seen anything from UT to say they will fix it. I think part of the justification for this is that these are demos of what people can do in Unity if they have the right graphics programmers on their team, rather than assets Unity ever claims will be supported over time.

A perhaps even more dramatic example is that when Unity were working on the 'new' standard assets, the person from UT who spoke about it on the main forum thread at some point admitted that they had moved on to other projects, and at the time they said that I think the new standard assets were barely out of beta.

I can live with such realities I suppose because these are not usually core features and there is a lively asset store where maintained alternatives can often be found.

 

Oops I forgot....

I wanted to contrast the negative aspects of my above post with whats happened so far with the Cinematic Image Effects - I'm really happy and impressed with how those effects are evolving, the updates to multiple branches, the forum communication etc.

So in my book the Cinematic Image Effects are a great example of how to handle something that isn't in the core of Unity. I can only hope than 18 months-2 years down the line I'm not complaining about how dusty they have become.