Please Unity, slow down.

We're trying to be transparent here, and it's the nature of software. In taking a big leap forward on particles, the regression created was determined to be a non-trivial fix at this stage. The performance improvements done apparently traded off with this issue, and the right solution will take some time.

I thought I had linked to the public issue, but if you want more clarity: http://issuetracker.unity3d.com/iss...nges-depending-on-an-angle-they-are-viewed-at

 

@Alex Lian Fair enough, that is cosmetic and hopefully not a major issue for anyone.

Transparency is good, but as you understand from the thread many of us are frustrated with broken/incomplete/poorly performing features and the feeling that it gets worse, not better, with each 5.x release.

 

Alex,

I'm aware you mean "next release candidate build" by why call it a release candidate? It's not a candidate for release. You can't preview Mecanim, and if you accidentally have your Inspector preview open, it crashes? That's serious enough to hold off releasing. Skip the RC and wait until it's fixed, or better yet, since this is RC1, call it beta.

The problem is Unity is tied to a December deadline, so they're saying "release candidate has to be out this week" so it's released regardless of what state it's in. That's what this thread is about. If this was December and Unity found these bugs, it would go out like this (we just saw this happen in 5.2 where it only became usable in 5.2.1). By calling this a release candidate, you're signalling to us that you think this release is acceptable for use and not just testing, and it's clearly not. Please, not another 5.2 -- I can't spare the time to work around all of these issues.

 

@Jodon Agreed. I wonder why Unity is so steadfastly trying to pass of beta versions as RCs, or even stable, public releases. Which brings us around to the very point of the thread: Fix the problems. Release when you have something really solid, not before then. Thanks!

 

Since the release dates have been carved into stone the definition of release candidate has changed as well. As far as I have come to understand, the first release candidate is now the cut-off point where development on planned features is halted, unfinished features are moved to a next dot release, and after which only testing and fixing of the finished features takes place. Which, mind you, doesn't automatically guarantee that testing and fixing will be completed at the equally carved into stone date of the public release, as such is the nature of software. The paradoxical effect of those carved into stone release dates is that version numbers and public releases are meaningless to me and stuff is just done when it's done - similar to Blizzard Soon and Valve Time. Much less stressful than getting personally hung-up at, let's get real, fundamentally arbitrary, as such is the nature of software, carved into stone release dates.

 

There are pros and cons for fixed and flexible release cycles. As Unity is an application that can never be seen as finished as it is constantly changed, the comparison with games is lacking in my opinion.
Unity has been changing a lot regarding the releases. A lot of us are happy about the the patch releases and the accelerated release cycles. Yes, there were many issues in Unity 5 and also recently in Unity 5.2. My impression was that they already learned quite a few lessons from those releases. My impression was that sometimes fixes were rushed and were either back in the next release or had unwanted side effects. This almost never happened during the beta of 5.3 for features that I was using. There will always be cases where certain features don't work. But this happens everywhere!
I am looking forward to 5.3!

 

Everybody is tired since Unity 5.
I have never got a real big problem in unity 4 but since unity 5 is out, it's really crazy. I'm scared to update my project to the last 5.2 cycle now so i stay in 5.1.3. When you can see that he release a full version with a broken input caret , wtf....
They work already on the next version when the actual on don't work properly ....
4 months left before the anniversary of Unity 5 and it's still not stable... seriously, fixe your broken produce and then work on the next.
I'm not angry on anyone but just tired to see the current situation.

 

It is probably not possible to "hold on for a few months and fix everything", because 'fixing' actually leads to implemeneting new featues, and on every cycle, that leads to more problems again - like a dead loop cycle, but I can see Unity doing as much as possible - like, patch releases.

Still, I am very tired fighting constant issues too, so what I would really like to see, is 'Release Candidate' being true 'Release Candidate' - i.e. do not push new update to public, until all knows issues are solved for RC. For example, right now I'm dealing with substance issue dragging back from 5.1p1 release, and this release will go on ignoring this one and many other issues just to be solved later. It should not be this way, for sure. I do not need new features, if I can not work comfortably.

 

You are correct. Still, I would like to understand one thing. What is the purpose of releasing products every month? Does Unity have some kind of inner obligation/contract? What is holding it from releasing only stable solutions, once it is ready? If every month release would bring joy and happiness - that is the one thing, but when rushes release is nothing but pain, I start questioning myself - why? No one will ever blame Unity for holding releases for several months, if they come up stable and fun to work with - am I wrong?

 

Unity is in competition with Unreal Engine. Maybe by releasing new versions quickly, they try to deliver the impression that Unity's development is more active and rapid than that of the competitor. Do you remember the time when the Firefox browser's version numbers jumped up like crazy just to keep up with Chrome? I certainly don't agree with such policies.

 

I wish Unity could switch to a release cycle like Blender's. As Unity, Blender is also evolving rapidly, adding a lot of new features and changes each release and everything always runs smoothly and the software is rock solid.

They usually set feature targets and date targets for each 2.XX release :

• BCon1: TimeWindow1 (define targets, branches reviewed & ready)
• BCon2: TimeWindow2 (start add branches to git, targets are defined)
• BCon3: TimeWindow3 (testing and fixing period)
• BCon4: TimeWindow4 (provide test build, fixing only)
• BCon5: TimeWindow5 (git frozen, RC a few days after)

Their planning is very flexible and the targets and time windows change accordingly to the development advancement. Often a lot of features get postponed to a next release because it didn't reach in time the quality standards, and they are not afraid of delaying RC versions if there are too many bugs.
http://wiki.blender.org/index.php/Dev:Doc/Projects
https://code.blender.org/2013/06/blender-roadmap-2-7-2-8-and-beyond/
I really like this organisation, blender is evolving at a very good pace and no one gets hurt in the process.

 

If you open your eyes, you will see that Unity is indeed doing something comparable. You can see the targets for the releases in the roadmap. They are added to the branch for the next release, go through alpha, beta and release candidates. In the case that there are issues with specific features, they are taken out and delayed for another release. At the end there is the release of the official version.
In general comparing Blender and Unity development is pretty hard, because there are just a few full time developers working for Blender. And they have very weak, community driven testing. That's the explanation for the many a and b releases that are required. Every Unity update has a lot more changes than a Blender update and even Blender updates require a and b releases and have a huge list of known issues.

The difference is most likely that you don't experience those issues in Blender, while you are not lucky in Unity at the moment. There are too many differences between Blender and Unity in my opinion, that a comparison doesn't make a lot of sense.

 

The idea of regular updates is to make them stable as well. For every release cycle, the new features are defined. If something turns out to be not stable, it is take out and delayed for another release cycle. At the same time, the bug fixes can be integrated. That is the overall idea.
This is important, because users are getting regular updates like that. That means if certain issues are resolved, the customer gets the improved one as quickly as possible and it doesn't take several months.
The weekly patch releases can also be very handy for situations like requirement for the app store to only allow new submissions with 64 bit and 32 bit versions. This required Unity to integrate il2cpp very fast, even though it wasn't ready yet. But they were able to react very fast to issues and customers could get those improvements within days.
With slower release cycles, it may have taken months for us to get il2cpp at all and if we had experienced issues, it would again have takes months to resolve them. With some luck they would have been fixed properly within two release cycles. This would have been a nightmare for many of us!

 

I just said that I found Blender's release cycle more flexible and leaving a more appropriate timing for stabilizing stuffs. They don't hesitate do take a few weeks delay if needed. Maybe they also have a higher threshold before considering a new feature as "ready".
During the creation of Haven Moon, I went through a lot of blender updates and I didn't have a single problem, I didn't even have a single crash. I really can't say the same for Unity.
When I opened this thread I just wanted to say that taking a bit more time for polishing stuffs instead or releasing as is and rushing for the next batch of new features is becoming a necessity.
When you see Unity being greenflagged for the release candidate state with big ongoing changes like in the new Multi-scene features that's not reassuring at all.

 

If there are fixed release cycles and a feature is not ready, it should be taken out. The stabilizing happens during the testing and if the time is not sufficient, it needs to be removed. Unity still needs to improve that process in my opinion. But as already mentioned, my impression is that this is constantly happening.

I completely agree that there were big new features that should have gotten more polishing. But I don't believe that the Blender process should be adapted for that. If a feature is not ready, it should be taken out and delayed. But even if that is being done, just taking it out is not always going to be that simple, which means the decision needs to be made early. If it turns out that after the decision was made, some major issues appear, it could even be worse to remove the feature for the overall stability. So even if the approach is more conservative, it is not easy to handle that.

I haven't tested the multi scene features at all, so I can't talk about it at all.

 

I haven't read all of this thread but apparently there are quite a lot of people unhappy with the stability of unity lately, including me.

For us the situation with 5.2 was like this:

• 5.2b1 – beta, cool we'll check it out. There are some problems but it's still a beta, We won't update in a real project anyway
• (...) more betas
• 5.2b6 – cool, new beta! will check the new features in a test project, but it's still beta so I don't have to try too much with real projects.
• 5.2.0f1 – release candidate! yay, soon I can update my projects, expecting a stable version.
• 5.2.0f2 – release candidate? checking if my projects would still work after updating, they don't. at all. lots of issues.
• 5.2.0f3 (release) – trying again, still no luck. too many issues. unity crashes all the time. animations don't work properly anymore.
• 5.2.0p1 – a few bugfixes that affected us, but still too unstable
• 5.2.1f1 – hoping for stable release, but experiencing too many issues
• 5.2.1p1 to p4 – hoping for stable release, but experiencing too many issues
• 5.2.2f1 – pretty ok finally, feels like a release candiate with some bugs, but mostly stable
• 5.2.2p1 to p4 – still some issues, but good enough to upgrade projects not close to a release
• 5.2.3f1 – pretty good, feels like a stable release to me.

The problem was: From 5.2.0f3 (official release version) we were expecting a stable version that works with our projects. In reality, this version was just another beta. A version that we would consider a release candidate was 5.2.2, and 5.2.3 was something like a stable release.

Between 5.2.0f3, released on sept 8, and the actual stable version 5.2.3f1, released on nov 19, there were more than 2 months and 11 (!) versions (betas or release candidates in my opinion) we had to install and test until we finally had a stable release that worked well with our projects. It just takes too much time. Ideally we have to update once every few months (5.1, 5.2, 5.3) for each project instead of downloading a new version every week to check if it finally works.

In my opinion, there's no problem with the speed of development or the general release cycle, but there's a big problem with the naming of the releases. In 5.2 it took more than 2 months from official release to an actually stable version, why not just take 2 months more time from feature cutoff (I guess beta 1?) until you call it a stable release? If everything until 5.2.1p4 would have been called a beta and everything between 5.2.1p4 and 5.2.3 a release candidate, probably there would have been a lot less comments about all this here. 5.2.0f1 could have been just a public (non-pro) beta to get more feedback from the rest of the community.

Right now, we don't even expect anymore that any releases before 5.3.2 or 5.3.3 are actually supposed to work well. I might try 5.3f3 when it is out assuming it's a beta and wait a few weeks before seriously considering updating projects. Let's hope the Unity team will do something to change that.

Btw. there's still a pretty annyoing crash bug in 5.2.3, which was introduced in 5.2.. no idea why nobody even looks at the report (simple repro included). Somebody in the thread said it was looked at but I never received a confirmation. And the bug doesn't show up in the issue tracker and is not fixed in the most recent version.
http://forum.unity3d.com/threads/5-...in-linux-headless-builds.354031/#post-2388683

 

The present release policy is just a façade. The fact that regressions occur time and again with extremely basic functionality – such as Unity crashing when changing scenes – is evidence that Unity's QA process simply is non-functioning. The fact that regressions occur in the first place and at this rate is also proof that internal development certainly isn't test-driven, and that Unity's programmers rarely run any general test suites outside the scope they're working on.

The really disastrous thing is that regressions sometimes are deemed acceptable. But regression errors will inevitably impact the existing user base. If you want to keep your users happy, please stop thinking regressions can be weighed against new functionality. It's a fallacy with software as complex as Unity, and I really don't think Unity can afford it.

Fix these two problems, then start thinking about implementing a more honest release cycle policy. Unity did so once before when responding to customer demands for transparency. We were very grateful for that, and it was a bold and necessary move. However, Unity overshot the mark widely, and what we have now is turning into a business hindrance.

The shiny new features are basically worthless if foundational stuff keeps crumbling randomly. And if your Pro users hold off upgrading to new releases for many months, well, then, effectively, you really haven't released much at all, have you?

A slower release schedule is fine. Alienating paying customers isn't. Unity must understand this.

 

Agreed on this. Written a lot on it before

http://forum.unity3d.com/threads/pro-users-are-you-getting-better-support.340187/

 

I got a reply a few days ago on a bug report I filed more than six months ago...

I don't want Unity to slow down, I want them to just STOP for awhile and fix things.

I'd like to see the new patches coming out with nothing but bug fixes for a long time. Like the other guy who just announced he's leaving Pro because of it said, maybe have a stable branch and an experimental/buggy branch if they really deem it necessary to keep blasting away on new stuff all the time. I could live with maybe 10-15% of the patches breaking my project, but it seems closer to 90% right now. Unacceptable.

From where I'm standing it looks like internal testing needs to be done much more thoroughly than it currently is. Please don't consider your users to be testers. I didn't pay for that and don't have time. If you haven't done so already, think about assigning a couple of people to produce game prototypes internally. That'll reveal a lot of the bugs which means the guys wading through bug reports will spend less time dealing with that. It can also be done a lot quicker when the guy reporting a bug is sitting at the desk next to you.

I don't know, maybe I'm wrong, but it's hard for me to imagine that all these bugs are doing anything but slowing down the development process on the new stuff anyway. I've never understood this manner of software development. When I spot a bug in my software (whether it's using Unity or my own software) I stop 95% of the time and fix it before continuing because that bug just leads to more bugs, and sometimes fixing that first bug causes new bugs in the new stuff I've done since on top of it. Even in a team environment I've always worked that way. I just don't understand that approach to development, especially with a project as enormous as Unity. It's great if the bug count is decreasing, that means they're on the right track, but until it's been reeled in to an acceptable level it makes no difference at all to my daily grind.

When you've arrived at the point where you've instituted an online system so your users can vote on which bugs to fix next, you have too many bugs and need to reel things in.

I've felt like my project is held together with duct tape and string throughout most of 2015 and still is. Upgrading the last many months has been so scary I don't even want to try to do it again, but unfortunately I'm going to need to soon. I really don't know if I'm even going to find an acceptable version of Unity for my project even with all these patches and versions floating around, and that's something no user that shelled out $1500 for the product should ever find himself wondering. If one or two patches out of ten breaks something, fine, but I shouldn't be wondering if I can even find a single patch that will work acceptably.

I'm still glad I'm using Unity at this point, but I'm getting increasingly frustrated as time goes on so I don't know if that will last forever. Some things need to change if I'm going to continue using Unity Pro and recommending it to others.

 

People keep saying how Unity keeps adding new fancy features instead of fixing bugs.

So I have to ask. What fancy new features?

Most of what is added is to fix an area that Unity is lacking, it's not a "shiny new feature". You're asking them to slow down, but from what?

 

Take your pick.

https://unity3d.com/unity/roadmap

 

I'd rather it looked like this until the bug count is sufficiently low to get cranking on new stuff again:

 

They can start developing new features ,that's no problem. Just make sure its tested properly before releasing into the main branch. Alot of the features don't work well together in production, only in demos only. Those should be fixed.

 

Well, as far as 5.3 goes, at least half of those are bug fixes.

For example : "Animation: Euler animation curve import" may sound like a feature, but if you ever tried to make a sudden camera cut with the old animation system, you'd know how broken it was since, well, ever.

And "SpeedTree: Billboard Improvements" may sound like a feature, but what it really wants to say is "Billboards might actually be usable now".

"MonoDevelop 5.9" might sound like a feature, but considering how messed up the old monodevelop is, I'd say it's a bug fix.

And that goes for most of those "Features" apart from say the 2D stuff and the Particles.

So what we are getting is indeed mostly bug fixes.

 

No new feature for 9 months? If you think the current model is bad, your propose model is suicidal. Unity can use some improvement in the testing and releasing process, but not as you proposed.

 

There are at least three completely different ideas about what Unity needs to make better. The ideas are not compatible with each other at all, but the supporters still agree with each other. That doesn't really make sense to me.

 

I would hope there aren't so many bugs that it'd take 9 months to fix them all. If there are, well.... That's not good.

 

In a code base like Unity, they could most likely work 4 years and still have bugs. Unity is not an isolated piece of software. It has many dependencies, runs on many different devices with different driver versions. If you want bug free software, you shouldn't use a computer.

 

And the other half aren't.

 

Let's not get pedantic. There are too many bugs here. That needs to be brought under control. I'm not expecting zero bugs. Don't be silly.

 

Yes, but updating outdated systems and adding some stuff that are useful for fixing other stuff, is not exactly them neglecting fixing bugs in favor of features.

 

In short,

Unity has a lot of issues.

They should be fixed.

I want the fixes faster too, but I don't think the solution is for them to focus on bug fixing, because that's what it seems to me they are doing already.

I don't know what the solution is.

 

Ok, I'm wrong. Unity has developed no new features in the past year. Only bug fixes.

 

Focus MORE on bug fixing and less on everything else. That's my point.

 

I don't appreciate the sarcasm, especially when you provide no counter argument.

 

http://www.medicaldaily.com/sarcast...vity-all-linked-sarcasm-study-suggests-344808

This may come as some surprise to you, but I didn't come in here to have an argument with you. I'm expressing dissatisfaction with the number of bugs that break my product which I'm currently in a process of trying to release. As have many other people. I'm explaining to Unity, not AcidArrow, what I need to see change in order for me to remain a Unity customer in the future. I don't really care if you agree with me or not. It's an opinion. You express yours and I will express mine. Unity can then read both and decide what, if anything, they want to do about it.

Have a lovely day.

 

SSRR .
It's a very nice addition but in 5.2 and first betas of 5.3, it broke the previous reflection system and had some bad side effects.
Each time I try a new version of Unity (beta, rc or final) it feels like my project is exploding. I get a crack ton of errors in the console, weird behaviors, some things are finally fixed, others get broken, etc (my ocean is now broken with the latest RC, will have to find where is the source of this new problem…).
So, from my point of view Unity in it's current state is not a software that I can call stable, it's currently more like a Russian roulette.
Fortunately the QA team is aware of what we are saying here and I believe the situation is going to be better.

 

Okay, then, for the record I completely disagree with you and hope that if any dev looks here takes that into account as well.

Have a nice day. (I am being sarcastic, I hope your creativity is as stimulated as is mine)

(EDIT: For clarity, I am referring to @Todd Wasson )

 

But that's not even a feature that is out yet. (and it won't be for 5.3 either)

Again, I am not arguing that the engine doesn't have bugs.

 

But unfortunately the first stage of SSRR implementation affected version 5.2 and made it's reflection features close to useless :-(

 

You mean the "deferred" reflectons? They didn't flat out break reflections, it's just different (it enables other workflows, for example nesting reflection probes works much better now). For example in my project the deferred probes work better that the old ones.

And people called the old system "broken" because you had to separate the geometry for inner and outer walls and it didn't facilitate non square rooms (which is where SSRR helps a lot).

But okay, that's a feature. I never said there are zero features.

In the end, my argument is this: Unity is in 80-20, bug fixing to features ratio right now, at least that's how it looks to me. This thread makes it sound like it's 20-80 the other way around, when it is pretty clear (to me) that it's not.

Some people seem to want 100-0, although they fail to articulate why they think it should be so.

And again, as I said, I am not arguing that Unity doesn't have a ton of broken features right now. I just don't see what this thread suggests as the solution.

 

What's clear to me is that I'm struggling to even find ONE version of Unity that I can use to release my product with because there are so many bugs.

 

I'm sorry, I thought you didn't come here to have an argument with me.

 

Dude..... How old are you?

 

Please accept that some people had different problematics than yours. I'm happy if this problem that you don't seem to fully understand didn't affect your projects, but for mine and other's this issue and it's side effects (on bark textures for example) were really critical.

This thread is not about telling Unity how they should work or set their bug fixing vs new feature development ratio. It's about raising awareness on Unity's recent lack of stability.

As Unity's QA announced that improvements are on the way I think this thread's goal has been reached a long time ago and as it's becoming a mess, maybe it should now be closed.

 

http://forum.unity3d.com/threads/reflection-probes-best-practices.277224/

This is why they changed the way the probes work

 

Alright - this thread has devolved. Closing.