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.
Actually we’re not; in the interests of improving stability and lowering our risk of regressing stuff, we’ve been gradually raising the bar for what we accept in 5.3 patch releases such that the majority of fixes made in 5.4 now will not be allowed into 5.3. This has been the situation for a few weeks now.
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.
A lot of users would not consider mixed-mode lighting and GI bakes to be core features, though - anyone making a 2D game, for example.
If it were something that really everyone uses - say, if we’d broken the ability to instantiate a prefab - then we absolutely would delay the release to fix it.
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 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.
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).
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.
), 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…