Hi wanna ask
Will it be such release-?
i don’t think so.
why would you need it?
there seem to be bugfix 2.79 builds that are newer than 2.79b though:
Stable release with old UI
Useful for work
Even LuxCoreRender is builded for 2.79b
No. 2.81 is in the middle of development and 2.82 early Alpha is just around the corner. 2.79 is done.
And both are still slower than 2.79 and not as stable and reliable.
For serious projects production a last release of the 2.7x series updated with the latest Cycles improvements would be welcome.
You’re not going to get the 2.8x series stable faster by putting development time into 2.79. Just saying.
Devs don’t work on 2.79 anymore, either someone has to report a big problem for it or they find a major bug that it’s in both 2.79 & 2.80 to get a fix but it won’t get an updated version.
Also keeping the 2.79 branch updated with bug fixes and improvements along the 2.80 development took time, and for what?
Now we have an unfinished last night build, with some imperfections and some gaps, that could still serve for a long time to those who need a stable and fast version. Just saying.
Honestly I don’t find 2.80 any less stable then 2.79
me neither, because I don’t use 2.8, I rely on the reports I read.
You’re just facing the conundrum faced by everyone who still clings to the prior release of any software product: “you’re left behind, all by yourself.”
are you talking to me?
The BF would first need a developer whose only job is to backport commits that can fit into 2.79 (ie. not breaking the workflow). Backporting some Cycles commits could potentially be done, but it would be far harder to backport commits using code that was changed for 2.8 (because of how 2.8 overhauled many areas rather than just build on them).
Use both, you’ll adapt to change soon, simply free your mind of anger and take it a s a kid with a passion to live forever and learn more (even your soul will be grateful). I was angry too, but now I simply switch between Blender 2.81, 280, 2.79, 2.78 and even earlier releases or other SW when need occurs.
Just report all the bugs and issues you stumble upon.
I know it takes time, but as we communicate and report, the better, more efficient and optimized tool we’ll have to work with. We all better our lives in open community. You can’t put a price on free will 
IMHO, a new interface will always seem slower in the beginning simply because the user is not that familiar with the interface. As the user becomes more and more familiar with the interface, the program automagically starts to work faster. I am in this boat, too: I prefer 2.79 - I’m familiar with it, but I started to use 2.80 in parallel because I acknowledge there is no turning back.
I, personally, don’t like the 2.80’s interface: it is not ergonomic (again, IMHO). It is crowded, there are too many icons, important icons (like the splitting screen yellow triangles) are missing or hidden some place, the top header is full of buttons (workspaces), etc. I guess this is in order to cater to all people who tirelessly complained about 2.79’s interface.
However, I do like the fact that the Blender 2.79 keymap and the option to use the right mouse button was retained . It’s gonna take some time for me to learn the 2.8x keymap. 
@Ace,
you are right, and I agree that continuing the development of a previous version would be non-productive at this point, and mine is not a request.
The fact is that up to a certain point in the development of the 2.8 branch, all the compatible changes were also brought to the 2.79 (cycles nodes, denoising, brushes and so on), then the process stopped suddenly leaving the last 2.79 built in one hybrid and buggy status.
It’s a pity because before the 2.8x series can be fully productive and fast, much more time must pass.
@PilotFerdi,
I don’t like the 2.8 interface too, but I could adapt if my workflow was not compromised by the changes and by the sluggish and slowness in editing, and anyone who denies this, obviously does not work on sufficiently demanding and heavy models and scenes.
I understand what you mean. It’s just a matter of life that the initial versions of a complex software are buggy, and the software is improved (speed, features, bugs removed…and replaced with other bugs
) on subsequent versions. I believe @burnin’s advice is wise.
I understand very well that it takes time to refine a new version, that’s why in the meantime we still need an optimized version that allows fluid work for those who need it; we have it in the 2.78b, but we could have several improvements that are in the last 2.79 build if it were not for the fact that it needs a final revision that has never been done, so as to make it become a release official (2.79c)
I am sorry but I cannot force me to use the 2.8 only to report the bugs, I need to work first.