Wow. Not a lot of programmers here I guess. Word to the wise, the idea of a ‘stable software release’ is just silly. Can you fix bugs - yes. Can you plan for every single eventuality in the universe - nope. For instance, you don’t know that if you try and put a walk cycle on a gun the editor will crash because ‘Who the hell does that?’ - why worry about it. , of course, somebody does it. Somewhere, someone will always have a problem with what you have released because they will try and do something crazy (or creative) and the editor will crash or freeze or whatever. you get posts like ‘Why can’t I do this?’ and Epic will try to figure out whether it’s worthwhile to implement it. There is no other way to do this. I have had UE4 crash, literally, ONCE since I first downloaded it. The next day I came to the forums and found a solution within 10 minutes. That was a month or so ago. UE4 has MAYBE 10 times and even never for more than a few minutes (a pain, yes, but Photoshop freezes WAY more often and I don’t go complaining to Adobe - AND PHOTOSHOP COSTS MONEY). I will say, however, I have no interest in creating multiplayer or online games. I just don’t play them, and have no interest in them. So maybe I’ve been dodging bullets but so as far as stability goes I have no idea what you guys are talking about. UE4 has been one of, if not the most stable piece of software I’ve ever owned. BUT… I WILL throw in a vote for the idea of focusing on fixing things FIRST and implementing experimental features as soon as possible (which, by the way, is probably what Epic does anyway). One thing I will say though is that there are certain things that are ‘given’ in game design that UE4 SHOULD have already set up. I’m talking menu systems, save systems, base weapon classes, etc. There are very simple things you NEED to have in order to even have a game… period. They can be customizable but having to completely code AND debug a menu is a pain when has to have one and there are examples. Why not just take the example and make it a customizable part of the starter content? It’s really a waste of time to go through the process of copying ALL that code (and that is what I think a lot of people end up doing anyway). And the whole ‘Save System’ debacle. Wow, just…wow. How many different tutorials are there - a dozen, two dozen? And half of them don’t work because they’re outdated! LOL Give me ONE good system that I can customize with my own variables, all ready to go in the engine. If somebody wants to expand on it they can, but give me a starting point instead of an example that I have to wade through.
Maybe we can setup some kind of community driven hot-fix system here?
The idea is to gather most of the critical bugs have been fixed in master branch (4.10) but not in current released version (4.8.2), backport/merge them in a hot-fix fork, so instead of waiting for the official hot-fix release, we can simply pull or cherry-pick from the hot-fix repository, test it and report back if any problem found.
I suspect many of of us actually already doing that all the time, but wouldn’t it more efficient to make it a joint effort? Take the bug UE-17464 “Variables reset after packaging” for example, it’s fixed in 4.9 branch and only took couple minutes to merge and build in 4.8.2 branch, but I would probably never know about the bug until I saw this thread, and I bet it’ll take me much longer than couple minutes to figure out it’s an already fixed bug when I run into it in my own project.
I read that blueprint is the one which caused much of the instability. Those working with C++ code may find UE4 very stable. I think some of the complaints here are very legit - if it is a blocking bug (you cannot move on with the project), it is going to be frustrated. And with new bugs introduced in the subsequent hotfix or major release, that is double .
However, I believe things are starting to stabilize. I can live without blueprint. However it is so much easier to instruct junior programmers to use Blueprint…lol
[=;339636]
Maybe we can setup some kind of community driven hot-fix system here?
The idea is to gather most of the critical bugs have been fixed in master branch (4.10) but not in current released version (4.8.2), backport/merge them in a hot-fix fork, so instead of waiting for the official hot-fix release, we can simply pull or cherry-pick from the hot-fix repository, test it and report back if any problem found.
I suspect many of of us actually already doing that all the time, but wouldn’t it more efficient to make it a joint effort? Take the bug UE-17464 “Variables reset after packaging” for example, it’s fixed in 4.9 branch and only took couple minutes to merge and build in 4.8.2 branch, but I would probably never know about the bug until I saw this thread, and I bet it’ll take me much longer than couple minutes to figure out it’s an already fixed bug when I run into it in my own project.
[/]
Thats why i more public bug tracker where anyone check on bugs and there status and help seach for hints of possible workarounds or if there any hotfix in github, Epic giving us those UE-xxxxx IDs but there no place to have any reference to them.
Yeah a public bug tracker would definitely be nice, but I guess Epic fears that people see the list of thousands bugs and think unreal engine is buggy before they even start using it.
If there would be a public bug tracker it would be really helpful, I would read through all the bugs to know at least where I can expect bugs.
[=;339761]
Yeah a public bug tracker would definitely be nice, but I guess Epic fears that people see the list of thousands bugs and think unreal engine is buggy before they even start using it.
If there would be a public bug tracker it would be really helpful, I would read through all the bugs to know at least where I can expect bugs.
[/]
We like the idea of the openness of a public bug tracker, it’s just a matter of resources that have kept us from pursuing it further at this time. I can’t offer a commitment right now, but I am still investigating and discussing the option.
Cheers
Why not just releasing regulary, weekly updates and use different ‘update rings’ like SLOW/FAST/LTS or something to get working bugfixes out faster? Seriously, waiting two months or more for a fix after it has been commited and tested is really not the perfect solution.
[=;339894]
Why not just releasing regulary, weekly updates and use different ‘update rings’ like SLOW/FAST/LTS or something to get working bugfixes out faster? Seriously, waiting two months or more for a fix after it has been commited and tested is really not the perfect solution.
[/]
Agreed. Could we not handle updates and new releases like the Linux kernel guys or some Linux distros do it? Have a stable, unstable, and maybe even a testing branch. Epic could work on new features (and of course also bug fixes) and release them to the testing branch. That branch is updated every few days – or even “in real time” via GitHub, for those who want to have the latest and greatest (any mabye buggy) features.
After some time (and testing by non-Epic devs who use GitHub sources, as well as Epic themselves) features move from testing to unstable branch. Could either be GitHub as well, and/or also regular releases of unstable binary releases. People who download and use that branch are doing so on their own risk, even though it is usually not as buggy as the testing branch.
Those features that have been stable for a while in the unstable branch move on to the stable branch. And that becomes the “official” version of UE(4), supported by Epic. People using that branch know that it is the most stable, even though it’s lacking some brand new features. That way we could also easily update the patch number of the engine quite often (e.g. 4.8.1, .2, .3, …), by just pushing only bug fixes to the stable branch.
In my opinion the nice thing with that approach would be that can choose as he pleases. And since the whole engine is “Open” Source, larger studios (i.e. with enough manpower) can still stick to the official releases and patch new features and bug fixes from GitHub into their own code base if they want. For me, and what I can read in this thread also for some others, this would be great because I don’t need the latest and greatest features all the time, I am quite happy with what the engine has to offer already. I am much mor interested in a very stable engine and editor …
Whilst I don’t appreciate the editor crashing, as long as the build release for customers is stable I can put up with the engine being a little buggy (to a certain degree). Whilst I’m sure our team will have much fun spending days / weeks or months de-bugging an engine and beta testing the game as much as humanly possible, having a certain level of stability throughout would be much appreciated.
One of the factors in us using a pre-made engine is support (to save time as time is money), whilst I appreciate the editor is free. Once a game goes on sale, it’s not as “free” anymore.
Whilst an engine is of course ever evolving, I believe UE4 is already very much ahead of the pack and very capable. So at some point it would be nice if there is less work on major (potentially substantially engine breaking) features. In which Epic can work on minor updates and stability control, also factoring in “backwards compatibility” to some point.
If said major updates are going to implemented, they could be released quarterly or bi-annually with a massive sign saying can cause issues with previous versions. I understand patch releases, they are cool but three months later the older version is dropped like a rock and we end up having to spend more time and money for our engine developers to fix issues in that development release.
Or upgrade and have issues with compatibility, as our project has just been upgraded to 4.8 and again it has broke. As much as I’d like to keep ploughing time and money into fixing issues with every release. At some point we need to stick to a stable version and see the development through to the end…
I would like to thank Epic for there support so far, they have been very forthcoming, helpful and friendly.
Looking forward to hearing some more suggestions.
It seems 4.9 branch is already in feature freeze for at lease couple days now, and only getting bug-fixes commits backported from 4.10. I would expect a much more stable UE4 version by the time 4.9 hits preview stage.
+1
(+20, if it’s up to me)
While new features are very important, there’s nothing that breaks morale more than instability of the software. Recently I nearly gave up on UE4 because of that… (sad face)
It’s interesting to note that the current system of 4.7.x, 4.8, 4.8.1, 4.8.2, 4.8.3 very much resembles the system of preview releases. The last minor version before a feature release is the most stable one. The ones before it seem to be meant for testing and bug fixing.
So it would be most reliable to always use versions that end with x.x.3 or higher. However, nobody wants to stay with 4.7.6, when there is a new and shiny 4.8… It’s either frequent release cycles OR high stability. We can’t have both.
My humble suggestion:
Break down huge feature releases into smaller ones. Instead of releasing 20 features in UE 4.9, release 5 and test them very well beforehand. Make sure that what you release is stable. In any case, treat only preview releases as an opportunity to find bugs. Actual releases have to be dependably stable.
And how do you get more real-life testers ? Give incentives for people to use preview builds. (and make sure that preview builds are also usable)
This way feature releases would be more frequent. Though developing the same number of features would be a bit slower on average. Of course this would not be ideal for press releases (smaller Boom!), but it would be better for long-term reputation and retaining developers.
[=;339894]
Why not just releasing regulary, weekly updates and use different ‘update rings’ like SLOW/FAST/LTS or something to get working bugfixes out faster? Seriously, waiting two months or more for a fix after it has been commited and tested is really not the perfect solution.
[/]
We already have that, it’s just that it’s on GitHub.
I switched back from 4.9 to 4.8.3.
Too many bugs and show stoppers. Like this one: [Bug report] Light wont build in 4.9 without a SM_Template_Map_Floor - Rendering - Unreal Engine Forums
This is not the only one I’ve encountered.
UE4 really needs a stability release.
[=;394113]
4.10 is the quality of life improvement release it seems 
[/]
Would be really great, I am looking forward to it!
Optimization and bug fixes as well wrapping up experimental features would be preferred over new features. UE4 is already a feature rich engine; fix what you have add onto it.
There’s a bug report from several releases ago that still hasn’t been fixed in Paper2D.
, I +1 for this concept as well. Fix what is there, add what is missing of basic features. Examples? Why do we need a UE4 to come up with Advanced Sessions Plugin? This is basic functionality that should be in BP’s… same with most of what has added through his plugin. UMG, change text sizes in comboboxes and other little things that ‘can’ be done but in a round about way. The basics… and update the documentation … I daily see people struggling to accomplish things and they are stuck on old info that does not apply any longer… or doing massive amounts of work when they simply did not know a certain node existed.
I currently do not understand the way of working at epic. Currently its: make release -> create bugs -> create new release -> fix bugs in next release etc.
The result is no stable release at all, every release has some big issues. Why not apply bug fix patches during the release? Preview of course solves the biggest issues, but it still doesn’t guarantee a stable release overall. You can’t expect people to integrate bugfixes to a previous release on their own. E.g. its hard for small teams to get a stable product. For the bigger teams out there it is easily possible to look into bugfixes in next releases and try to get those working.
one solution its have another, “long stable version”, and upgrading bugs in that version, not new features or performance improvements just only bugs , but each release EPIC announce big and great changes and performance improvements. I think that will not be useful for something like a engine, i think the greatest part of users prefer that improvements in something not perfect and suffer some bugs than a “long stable version outdated”
You can’t have a new released with new features and bug free. Or one thing or another
[=knack;444716]
one solution its have another, “long stable version”, and upgrading bugs in that version, not new features or performance improvements just only bugs , but each release EPIC announce big and great changes and performance improvements. I think that will not be useful for something like a engine, i think the greatest part of users prefer that improvements in something not perfect and suffer some bugs than a “long stable version outdated”
You can’t have a new released with new features and bug free. Or one thing or another
[/]
bug fixes are bad newsbreak for marketing department, also they dostn fun to work on.