Not that I would ever understand, HOW do Blender foundation actually actively improve two versions?

So like what…any codes added to 2.83 automatically “bubbles” to 2.9 ?
What if there are so much difference (at some point in the process) that you cannot simply just “bubble” up the code ?

And what if one v2.9 programmer actually make the effort to re-code it so that the effect is the same but due to the way 2.9 is structured it is actually coded differently and then after that 2.83 had a regression when they realize feature X should not have been implemented that way and the 2.9 programmer that coded from scratch have to remove it ?

At some point doesn’t that basically fork the code base apart such that we will have a situation where 2.9 don’t have all the features of 2.83 ?

What a mess…why is this happening ?
For the hype ?
How is this even managed linearly as far as feature layering is concern ?

The only thing that brings great comfort is Ton is still in charge, I know and have faith he will keep everything “together”, if in an alternate universe this happens when he is not in charge…headache…

Hi, regular release cycles, 2.83 is finished in a few weeks.
2.83 is bug fixing and or small changes only, 2.90 is alpha status open for new features.
All bug fixes are merged in to 2.90.
Next cycle is 2.91-93 then 3.0 if I remember correctly.
The only difference is 2.83 get Long Time Support so critical bugs are fixed for the next 1-2 years.

Cheers, mib
EDIT: https://code.blender.org/2020/02/release-planning-2020-2025/

As someone who developed software for over 30 years, I can say, it’s actually par for the course to work on multiple versions at one time. It’s not really any different to working on a new release when you already have a product out.

That is already situation between 2.79 and 2.8x for Baking to vertex colors, Baking of displacement map, Particles rendering, Multires, some simulation stuff that mantaflow don’t support and probably other things that I don’t remember.

Probably most part of damage was already there in 2.80.
A part of 2.80 experimentation was solved in 2.81 and 2.82.
2.83 will continue to solve problems for 2.8x new stuff like Grease Pencil.

There is no reason to expect things going a lot worst in 2.9.
Particles nodes will probably not recover every feature of old particle system before becoming new default. But for sure, it will not be merged into an official release before bringing an improvement that old system was not able to deliver.

But except that, probably everything will be improved in 2.9.

Any refactor comes from a feature request.
Developer imagines a way to satisfy it. But it always has downsides.
Community is forced to make decisions.

When you replace something by another thing, you can not anticipate how early states of this thing will be perceived.
EEVEE was really well perceived. A “we want to be able to work with this thing, immediately” type of thing.
When that is what is said everywhere : that is not hype.
That is pressure which forces to attempt a release with regressions.

This plus the fact that 2.8 project was touching so many areas at, same moment.
You could not end-up with a 2.80 as functional as 2.79.

The fact that community is aware of expected regressions, it is related to its efforts to follow development, test patches and alphas, communicate with developers.

2.83 will be a freeze in terms of feature, refactoring. It will only benefit of bugfixes about stuff present in 2.83.
If something is refactored in 2.9, this refactor will not happen in 2.83.
If something is fixed in 2.9, that does not mean it will be fixed in 2.83.
(Probably developer will evaluate if an hack is possible to fix it in 2.83.)
An LTS is 2 years old, at its maximum.
That is not code that a developer working on 2.9 will not understand.
If he is facing old code that he needs to get through, he will probably have to do this work for 2.9, anyways.

Devs are organized.
Communication is a lot better than what it was during 2.5x.
developer.blender.org is a great site ; where everything is written down, before any task work begins. And any patch is reviewed before being accepted.
They probably can handle a LTS release.

Of course, time passed on LTS will not be passed on master.
That will slow down development of new stuff in master.
How much ? Nobody knows that is their first try to make one.

They don’t do an LTS for the Hype.
Currently, 2.8x are not reliable for production.
2.83 will be the release with the lowest amount of bugs and the most tested UI.
LTS guarantees a release that you can focus on, to learn its UI in depth during several months, being able to produce with it during 2 years and benefits from bugfixes.
That is not the case with a release cycles of 3 months that implies that if you need bugfixes → you have to upgrade your organization and pass time to learn what’s new.

So, definitely, LTS is not about maintaining hype.

Hype maintaining is just about renaming next release : 2.90 and adopting new numbering to release a 3.0 in 2021.
But probably, all 2.9 releases will continue to have lacks regarding to 2.8 project initial ambitions.
Sincerely, I doubt that 3.0 will have no lack.
I doubt that schedule will stay as mentioned. Because I doubt that short cycle of 4 releases per year will continue to make sense after UI stabilization.

Blender has a pretty fast and vivid development. That does not mean that is a mess.
But it is hard to follow, keep it on track and avoid that it missed a stop.
Because main driver is Community, its destination evolves with Community desires.

1 Like

Think of it like this…

You finish combing your hair, then you put on your shoes and start tying them…

But flies are buzzing around your head, so you swat at them to keep them out of your perfectly-combed hair, then go back to tying your shoes…

But there are more flies, so you swat at them, too, then go back to tying your shoes…

And you keep that up until all the flies are gone and your shoes are tied.

:wink: