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.
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
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.
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.
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.
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.
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.
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.
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)
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
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?
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.
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 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.
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.
