Shouldn't we be on RC's by now for June release [Roadmap]?

Shouldn't we be on RC's by now if you are still aiming for the a June release date [Roadmap]??

Or does the road map target date need an update?

 

Roadmap needs an update, but getting close.

 

Hi, it would be awesome as well to have a kind of log about of each feature in the roadmap, so we can see how the features are evolving, milestones, eta.. and to have the possibility to comment them.

Personally, I'm really looking forward to hear about .net integration and new profiles..

 

Thanks for the feedback! We're trying to keep the roadmap fairly simple else it might get pretty cluttered. We could link back to more of the feedback.unity3d.com points where further commenting might be possible. As for keeping running logs, we let devs blog where they feel appropriate.

 

And if I'm not mistaken, 5.4 will lead to more iterative smaller releases after as everything migrates to subscription rather than big releases?

 

How will this be different to patch releases, and then just .point release..

 

First step is trying to get back to a rhythm, but taking less change in each iteration. Working out what future cadence/periods are, and that's still subject to change sitll.

 

Yeah good luck with it! I know it's a bit of struggle especially so many teams working on different things that might rely on other things!

 

I say screw the roadmap; don't switch to RC until 5.4 is actually ready for release. Right now there are still way too many major issues. Unity needs a truly solid, stable release before they switch to subscription-only, otherwise it's going to lead to a lot of griping and anger. Subscription should be for new features, not for required fixes in existing features that have been broken since 5.0.

 

+1 Agreed as raised in few other threads asking for 5.4 final. Dont get some people on here, moan about the bugs yet dont wish to wait for stable release. I really wish for a stable release like 5.3.5 is pretty stable, I wish for same quality in 5.4 final public release.

 

So, 5.3.5 has more issue reports against it than 5.4, but people stating it is more stable.
Also, I also have people shipping games and final-ing on 5.4 beta releases already. I'd suggest that's a measure to consider for shipping quality.

Supporting 28 platforms that are all on the move, while also trying to fix some parts without breaking others, _and_ adding improvements and optimizations (and even with leaving out features) is work that will never finish. I have 3rd party libraries fixing one thing, but breaking another. Do I take it? Do I leave it out? Do I wait for something that might never come?

All of this, while other fixes and refactors are waiting in the wings and creating up another pent up set of changes (not even including features!) that people want but need some amount of time to vet in beta more than can be offered in 5.4. Waiting begets more waiting, and waiting also means more change tries to come in even if I don't want it. (macOS, Windows updates, VR plugin updates....)

Just to note, yes, there are some key issues we're looking to iron out before we cross to RC, and we look to this forum and others to help catch what these key issues are. So, please post away and offer specific bugs we can chase down. However, without knowing what you're looking at and saying it's not stable without specific bug reports isn't something we can actively work on.

 

The things I would like to see before Unity moves to subscription-only:

- All major graphical glitches in Deferred Linear should be fixed. Unity needs to stop releasing features that only work in Forward Gamma. If anything, Deferred Linear should be the primary method and Forward Gamma should come second.
- SpeedTree needs a working shader and fixed LODs and/or removal of LOD transitioning that breaks LODs; overall it needs to be much faster.
- Multi Scene Editing should work in at least the majority of basic scenarios. For example: having objects in one scene reference objects in another scene; combining scene-specific information like lightmaps and lighting, dealing with DontDestroyOnLoad correctly, etc.
- Lighting model and Standard Shaders should be finalized. Are you doing Lambert or not, are you tweaking normals or not, are you backface culling or not, are you sticking with GGX, etc. I don't like how the lighting keeps changing every minor version.
- Some extremely long-standing bugs that appear to have been given up on really should be fixed: the broken string serialization when importing prefabs and assets into large projects; the "open every single window in Windows when importing" bug, etc.

 

And this is Unity's problem in a nutshell.

I switched to 5.4 back in March just 2 weeks before the original roadmap had it released. I made all the changes needed making it hard to go back. Then Unity slipped, and slipped and slipped and is still slipping.

I cant go back to 5.3 and I cant rely on 5.4

But. I have a job making games, its a full time job, I have development, I have demo's and games to release. If I don't do that I don't get paid and I don't EAT.

So what you take as "a measure to consider for shipping quality" I take as sheer desperation.

Your main market may be giving this away to people who do it as a hobby and can wait six months for you to get a stable version, but many of us have our backs against the financial wall and dealing with broken betas and unstable systems makes life very stressful. I spend most of my time finding workarounds for your bugs rather than actually making progress on the game.

My confidence in Unity right now is near zero.

 

In the future, since there's not going to be Unity 6, how are you going to handle changes that break backwards compatibility? Will you be avoiding those or will they just be point releases with time to prepare, like 5.4 beta vs 5.3 stable?

 

May I assume given that subscription charging for existing perpetual users only hits next year, that this means there's room until then to keep making the improvements and shipping 5.4 is just a stepping stone towards that?

Thanks for the list. I'll pass to our Product Management to track and we'll do our best to address these things. Though concrete bug #s for some would be really helpful.

 

I see your point of view, but I'm also getting other customers pointing at it to as validity. It's another data point, as is tracking all the key issues I mentioned earlier. Many of us here have been in the game studio life, and we're consciously trying to balance it all as best we can.

While the hobbyist is a large audience, they are not the paying audience that keeps the lights on. We equally have similar decisions to make, and helping people ship games and be able to consider paying us is part of what we aim for.
So, we understand that concern, but can you offer specific bug reports here so I can assess and track them?

 

We're doing our best to make sure projects upgrade cleanly. As for future cases where compatibility breakages may become necessary, we're looking to give as much forward notification, parallel compatibility during deprecation and other such practices when those scenarios arise.

 

Well wait till 5.4 goes final and we see if the amount of bugs be more than 5.3.5..right now even with the bug bashing competition people dont wish to test because of worry, fair enough no force needed.

I get personal mails asking me what version I think most stable as there is fear of people upgrading from 5.2 to 5.3 version, not my job to help with upgrade process and make it clear that there are many benefits to upgrading..

I do not feel 28 platforms to support should be a talking point as most these platforms there not been any work done on or you fix a bug once in a blue moon- lets be clear here the standalone, ios and android are the main money makers for Unity currently, vr not matured.. And apart from the hardcore standalone developers who wish for perfection like Adam demo - us mobile developers do not have need or wants for hardcore features and such bugs as mentioned above not priority for us.

Hence mobile performance and mobile bug fixing most welcome..these are the platforms that are constantly on the move..

 

For me shipping quality means there is no major bugs in any platform. And by major bug I mean anything that can affect a high percentage of developer.
Unity 5.3 was shipped with several rotation issues on Android that was very likely to affect most Android devs.
When every day on the forum there is somebody new reporting the same exact issue over and over, I guess that's a major bug. You don't see many threads like that anymore about 5.3 now.
I'm sure there were several Desktop, console or iOS devs that shipped games just fine, but that didn't mean the release was stable then.

This is something that Unity need to address, because it's really annoying.
I reported a few bugs myself, one of them took two full days for me to isolate(cause I won't share my code, sorry) and to make it as clear as possible to the QA team.
After spending so much time on it, I didn't see any progress on it for 3 months and then I see read about several other bugs that have been reported multiple times and never fixed for years. I tried to ask for an update two times and no one answered ever. Would I report any more bugs? Very unlikely now.
No wonder you have to do contests to motivate people to reports bugs.
In case you are wondering, the bug is 784161 and make onAudioFilterRead allocate continuosly memory, quite a deal breaker in my opinion.

 

I understand your situation but professionals *really don't* do what you do. You are doing precisely what a hobbyist does - move to a version prematurely. Professional developers do not move. In fact you will have a very hard time convincing them to move unless it works perfectly beforehand. And where is version control here? I hate to nag but...

Otherwise I agree with you, it would be nice to depend on Unity. But heck, why are you moving products your business depends upon, to a beta version of Unity? Even mild testing of 5.4 back then would have told you it was far from stable. I nag because your situation is painful, one I can identify with that I wish you didn't have to suffer.

This is true of my Unity experience since 3.0. I'm hoping nowadays there's a real drive to make things a bit more F***ing stable. With 1000 staff, I feel confident I can demand stability.

 

Unless of course I had been waiting for your HTCVive support to become native so I didn't have to try to support 2 sets of plugins that other users were struggling with, and be able to use the SteamVR updates that only work with 5.4.

As you don't know what my business is, or how its run, or what version control I have, or how long I've been writing code your implication that I did not behave in a professional is deeply offensive and very unprofessional of you.

I have used version control on almost every single project I have worked and run for over 20 years. Your implication that after making changes to support 5.4, spending weeks and weeks on it, then getting frustrated by the whole process is simply resolved by undoing it all and reverting the project back months shows you don't understand the problem!!!.

 

No. You moved to a product that was not final. That was beta. And no matter what engine is used in software development, beta always means "use at own risk". You risked.

That said, I do think Unity has been historically a joke concerning stability. I am seeing them make strides now and putting real weight behind stability, but they will remain judged by their stability given the history.

 

I can't emphasise this enough. Too many people are stubbornly ignorant of this.

 

Yeah, I mean obviously the sooner things get fixed the better, but I'd be willing to live with a broken 5.4 release as long as I was reasonably confident that there would be a 5.5 before the subscription that focused on fixing bugs rather than new features. But switching to subscription-only is going to make me and many other people angry if something like "correct lighting in deferred mode" is held back as a "feature" that gets released one week after things go subscription-only so that we're forced to sign on for a year-long contract just to get a fix to something that was released over a year ago.

 

I hope you realize you are responding to a post that was in response to a Unity developer essentially telling him that 5.4 beta is currently more stable than the 5.3 release version. I don't think you can really be high and mighty about how people shouldn't switch to betas early when one of the developers is telling you to your face that the dev team and all the real professionals think the beta is more stable than the current "stable" version.

And I agree with freekstorm that this attitude from the Unity team is part of the problem and something that's bound to only get worse once they switch to subscription and not having any real "official" releases anymore. I had a bunch of bugs that I filed for 5.3 marked as "fixed" that are only fixed in 5.4 (some were from six months ago or more) and been told there is no intention of ever fixing them for 5.3, so there is a lot of pressure to switch early to betas if you need those fixes to release. Personally, I've still stuck with 5.3 and am just waiting for 5.4 to go to RC mode before moving my whole project over since there are new 5.4 bugs that outweigh the benefits of the fixed 5.3 bugs. All of this should not be such an ongoing issue; Unity keeps adding new features that cause system-wide bugs before they fix the old bugs which means that there hasn't been a truly stable release is a long time.

 

I can understand specific situations where there may be an antsy need to move on to new versions as soon as possible though, especially with Unity where so many basic things are missing from the engine. There have been times I've upgraded to a final, "stable" version of the engine only to find an ugly regression that wasn't in the notes (and I always read the notes carefully before upgrading).

Currently, our team needs - needs - sprite sorting groups ASAP. Just that one little feature. However, sorting groups are currently only in a very specialized beta of 5.5 that as far as I know isn't ever really updated. It's on its own little world. What if some aspect of 5.5 is a huge regression and messes up the project? Can't take that risk. And 5.4 isn't even officially out yet, so any final version of 5.5 that has this feature is some time away, I imagine.

So either I can not have the feature, or have it with the "you should have known better, beta software, you're not professional, etc." remarks. In other words, it's impossible to win. Every wall has spikes on it.

I mean, let's not pretend these kinds of issues aren't fairly common. There are even a handful of headache-inducing bugs that have been around for years that haven't been, and seemingly never will be, fixed. It's very easy to see how someone may feel cornered while using Unity depending on their needs, especially if they feel like they have nowhere to turn and nobody offering them support.

Further, I think the whole "professionals do this, no, professionals do this" is a pointless slap fight that's beside the point, the point being the current state of the engine and what's to be done about it on Unity's side. Professionals would also listen to their paying customers, but we see that certainly isn't always the case. Heck, I've never submitted a single grievance that's been looked at. I submitted a bug about something back in Unity 4.6, a bug that aggravates me nearly every day I develop, and it's never been fixed. I'm used to it, so whatever, it is what it is, but my point is that I can 100% understand the frustration.

All I can do anymore is cross my fingers and hope, as I've learned any suggestions or bug reports are met with the sound of silence. And that attitude from Unity isn't going to fly come 2017 when everyone will be expected to pay for the engine like it's a subscription service, meanwhile receiving no service.

 

- All major graphical glitches in Deferred Linear should be fixed. Unity needs to stop releasing features that only work in Forward Gamma. If anything, Deferred Linear should be the primary method and Forward Gamma should come second.
648897, 652932, 779420, 711787, 767327, etc

- SpeedTree needs a working shader and fixed LODs and/or removal of LOD transitioning that breaks LODs; overall it needs to be much faster.
790798, 744984, 731580, 744971, 727493, 807115, etc

- Some extremely long-standing bugs that appear to have been given up on really should be fixed: the broken string serialization when importing prefabs and assets into large projects; the "open every single window in Windows when importing" bug, etc.
681861 (not public), 805654 (though there are a bunch of similar reports, several saying it was fixed in different versions; it was never fixed.)
680013 (not public), but threads: http://forum.unity3d.com/threads/importing-a-package-causes-windows-to-open-all-my-programs.183993/
http://answers.unity3d.com/questions/585494/unity-causes-a-whole-bunch-of-random-windows-to-op.html
http://answers.unity3d.com/questions/419564/unity-opens-20-windows-when-importing-asset.html

 

I wish Unity made each feature (Mecanim, Animation, UNet, UI, ParticleSystem, Spriting, Physics, Physics2D, etc) as optional plugins so we could choose the versions of each plugin, to cherry-pick what is wanted for a project or not.

With each update currently, sometimes new features are excellent, but other things break. And if one thing breaks, that entire version is rendered useless until it's fixed.

Whereas with third-party plugins, I can decide if I want to upgrade to the latest versions of each plugin or not.

But with Unity's built-in features, I am forced to have everything, bugs and all (though hopefully without bugs).
Every Unity version is a gamble. "Hmm, is everything going to be stable this time?" Some users get lucky, others not so much. The mentality of expecting instability is annoying.

I am glad that 5.4 is being tested slowly, rather than forcing umpteen bugs onto everyone to satisfy some arbitrary release schedule, because shipping a "stable" version with known blocking bugs is not good for anyone.

Personally, 5.2.4f1 from Dec 2015 is my last known stable version (for my needs), and I'm hoping 5.4.0f1 will be the next stable version.

I am sure this is hard all in all, so thank you Unity for doing what you can. Being able to allow me to publish to multiple platforms is awesome. It's just unfortunate that each update is a mixed bag. Truly stable versions seem far and few, but I look forward to finding the next one.

 

I knew the risks, I had no choice as 5.3 does not have the features I HAVE to have.

I was not complaining about the delays, although it would be a legitimate complaint. I was objecting to the view of Unity that the beta was stable enough for release so effectively we were just whining about nothing.

 

Apologies, I read your post without properly reading the one you quoted. In context it makes sense.

 

but you always get all updates for free and at the same time as others users?

correct me i am wrong but this alerted me and could not find any evidence that you dont get upates without subscriptions

 

Free users will still get updates for free. But Pro/Plus users will have to stay subscribed because we will no longer be able to buy a one-time license for a particular version.

 

The more we stuff in a release, the harder it is to stabilize. So we're trying to bite off less at a time. Even if there's a pent up debt of things to address, we're working as quick as we can. So, a lot of what's on your list is on our docket of things to address, but some of them need time to get done and making 5.4 wait was certainly not the right solution ( but I think you get that)

 

*sigh*

That wasn't my intent, to be clear 5.3.5 is viewed as *more* stable, but it also has *more* reported bugs. I was pointing out that irony more so than comparing it with 5.4. 5.4 is certainly _less_ stable than 5.3.5 as I can't prove otherwise easily.

Part of the point was, I can't compare and determine stability quite that easily and there are various other measurements and mechanisms that we are factoring in.

So, this is a failure in communication on our part. Devs mark things fixed and try and fix the bugs closer to the trunk line than the shipped versions. So, by default we don't necessarily pull fixes back. In fact, there's usually a risk that with enough fixes, we end up creating a regression somewhere else. However, you can ask to see the possibility of backporting on the bug requests, but since all users don't need all bugs backported, we default not to unless asked and then check the possibilities.

So, the line of feature vs. other things is fuzzy. Optimizations are often a producer of regressions. Re-factors of systems as well. Truly new features usually hang off the side and don't break much at all....

So, is a replacement input system a feature or a re-factor?

 

So, of that set, UNet and UI are already somewhat in that set. Obviously there's some lower level hooks we must provide, but the push is to be modular and offer our version. The UI system can be forked and modified as you want for the higher level parts.

However, this can turn risky with the version matrix proliferation....

 

Did you see http://blogs.unity3d.com/2016/06/13/2d-experimental-preview/ ?
The team is working on creating a 5.4 branch with their features on top of it.

While you might view sprite sorting as a little feature, it's unfortunately invasive enough that we're taking our time with it and letting folk beat on it separately. I highly recommend considering trying the preview the team has. IIRC, They'll be aiming to keep it up to date with 5.4 as it goes forward.

Could we have bug #s? We have been fixing many many bugs, but things do get lost and perhaps the bugs in question haven't floated up. If you have something I can check on, it'd be something I could do.

I suggest you look at the blog post regarding our bug handling. We rely on high "rated" bugs based on information as we have a finite amount of processing of bug capacity we can do. So, things can slide by with silence, though we're working on improving that.

 

5.4 on roadmap has shifted to July, and as a reminder I would say people did ask for it to take as long as it needed to be stable.

But what does stable mean? a unity without ANY known bugs?

 

So, the graphics team would be better off discussing, but we are creating longer term plans to just make this all better. We're still working through the backlog of bugs.

Same here. We're working on a shader fix now IIRC, but getting perf optimizations also required us taking some time to get some other pieces in place which have mostly landed, but work has been moving forward here.

The ones above, at least 805654 is still open and we'll aim to get to it.

Asking QA to take a look to see what we can reproduce and therefore chase.

 

I do get that it's hard to try and keep a piece of software with this many moving parts stable. I don't envy your job. But, if this was a git repo I would say that each new feature should be a branch off the main trunk, and fixes should always go in the main branch. New features would always be "experimental" branches, not "stable", until they get through a beta period and get merged back in. Users who are interested in that feature could access that branch and test it; after a feature has been tested long enough, they would be merged one by one into main, with a separation of at least a week or so, giving all users the ability to see what particular bugs this one feature has added to the overall product. This would make it much easier for you guys to narrow down what causes what. Currently, all users get a new build that is just a big dump of different features, changes, and bug fixes, so it causes lots of bugs and no easy way to know which change caused them. I'd be way more happy about the "no more major versions" model we're approaching if there were different branches like this. At the very least there should always be a "stable" and "developer / experimental" branch available to users. Oh and the replacement input system is definitely a feature. Keep that thing away from the main branch until it's been thoroughly tested by everyone in that forum. Give them all an "RC" build a week early that is merged from the trunk, pause all patches on the trunk for a week, then release that RC as main if the forum doesn't find any bugs.

 

How would you deploy this to end users without source? how would they choose? How much of engine part A depends on B? maybe A can't be on another branch?

So Unity's solution is to make complete builds like the 2D stuff uses 5.4, but it's it's own build. It only focuses on 2D stuff... its the closest they can get to a "branch without source".

A lot of what you are saying has been thought through and there's no perfect solution for it other than custom unity builds like we get now.

 

I use Forward Linear and you didn't even mention that. That would be priority for me. I think Forward Gamma has to be the least needed rendering path.

 

I didn't even know there was a custom 2D only 5.4 build. Rather than keeping those private or only making them when a customer asks, they could just have all new features with their own branch. If new feature A requires new feature B, then they can be released together, but in general, that is not the case with new features. 5.4 has a lot of random new stuff all introduced at once along with what appears to be a huge refactoring of some basic parts like the transform hierarchy system. Some new features were introduced as late as a month or two ago, well after the beta should have already been feature-complete.

And yeah I know it's more complicated since customers cannot access the actual repo but I think they could still do installers for different versions. I know it's hard and I'm sure they've thought about it a lot, but I'm not willing to just throw my hands up and say "Oh well, software development is hard so I guess this is the best it can ever get." QA is something that can always be improved upon, and figuring out a better release management system is part of that.

 

Yeah I don't think any of the rendering paths should be abandoned, but currently everything seems to only get tested in Forward Gamma before release, so Deferred and Linear are always playing catch up after customers actually get the release and report back that things are broken. In a perfect world, they should do their QA with every rendering path (I don't know if anyone actually uses Deferred Gamma or Legacy Deferred Gamma, but if they're selling them, they should be testing them.) But if they can't test every path, they should at least not be using Forward Gamma as the main path. I think if they did tests at least on Deferred Linear and Forward Gamma, that would catch most bugs in Forward Linear as well.

 

But they do, the link(s) are in the relevant sub forums...

 

There have been blogs about it, and it has its own dedicated subforum. I actually found it hard to miss

 

and that's very close to what we're moving to with:

http://forum.unity3d.com/forums/2d-experimental-preview.104/

http://forum.unity3d.com/forums/new-input-system.103/ (New input system!!)

http://forum.unity3d.com/forums/linux-editor.93/

and more to come....

 

Cool, I did notice the input system and linux editor; I guess the fact that I'm exclusively doing 3D made the 2D forum disappear. But yeah I do think this is the right direction once you go subscription-only. Just make sure there's a plan for how and when to merge those features back into the main branch; ie do it one at a time with a week between merges to give users time to iron out bugs.

 

Why do you seem to assume Unity staff are incapable of doing their jobs? I mean most of your posts are based on the assumption Unity knows far less than you What is your job again?

 

Because so far Unity has not been doing things this way, and that's why 5.4 is running months behind schedule.

 

Like I said, I get that this is a hard job, but to pretend that Unity has a perfect and flawless record of releasing features on time and bug-free is delusional. There is a lot of room for improvement.