It’s on the work already for mantaflow
Do you have a source that the short release cylces have been introduced to reach 3.0 soon after 2.8?
Currently, there is no official GPU fluids testable by users. If it is not the case, now, It will not be in an official release in 2 months.
What is shared in those reports is the fact that Mantaflow’s developer stopped his work on GPU fluids to work on 2D Fluid simulations in a separated branch. The work done in a new branch will probably not end-up in an official release, this year.
But Fluids are out of scope. Yes. I made the mistake to write “GPU physics” in my reply. But it was a reply about Cloth and Particles.
I did not write it was introduced soon after 2.8.
That is my unofficial sum-up of pasted 3 years of improvisation.
None of this convinced me.
After disappointment that 2.80 will have obvious lacks and instability, choice to speed up release cycle to reach a satisfying release, as soon as possible, was made.
That does not make sense from a development perspective. Time necessary to incompressible work to reach such goal has to pass.
But from a marketing point of view, explaining to users that what they want, could happen in next release in a few months : that make sense.
And in the same kind of logic, abandoning the numbering of series from .0 to .9 to use a numbering from .0 to .3 to reach a round number like 3.0 as soon as possible make sense.
2.90, 2.91 and 2.93 has to been seen as 2.84, 2.85, 2.86 releases if you want to compare period we are living with anterior ones.
Maybe LTS should be compared to b or c releases.
With 2 releases per year, Blender release cycle would still be faster than comparable software.
And that would improved its reputation to deliver a safe LTS release per year after months of features testing of half of novelties instead of a promise of 2 years of bugfixing.
3 releases per year does not seem to match an agenda that would satisfy developers that are volunteers that may be volunteers still working at universities
4 releases per year, it is too much. On paper, that may match agenda. But in reality, they are not succeeding to maintain it.
2 releases per year as you are suggesting would mean the developers would get a lot of feedback twice a year. Or with the amount of users and feedback, they could be found within a huge pile of bug reports.
I agree with you that the initial quality of LTS versions should be better. But, this could be achieved by slightly adjusting the way releases are handled. One way would be to spend more time on those. Another one could be to literally take the previous release and simply make it the LTS version, meaning it went through lots of user testing and has gotten plenty of bug fixes.
Could you explain why you think that?
That should have no impact on feedback.
Yes, we could expect twice more duplicates report to close per release. But developers would have twice less release to treat. So, that should be equivalent.
If somebody make a duplicate report because he did not find relevant existing one, that nothing to do with how release is numbered.
Yes. a release would last twice longer. But months in a year are not doubled. In the end, users still have some amount of time in a year to make duplicates.
In fact, we could expect that existence of a bug could be more spread among communities of users. As a consequence, a doubling of duplicates should not happen.
We can also consider that some duplicates of reports are due to releases.
At the occasion of a release, people are more inclined to try blender, for the first time and wrongly report a long term issue as a bug, for the first time.
By decreasing amount of such events, you should decrease periods where bugtracker is massively visited.
Students who worked on a ggogle summer of code want to use it to promote them, the following year.
It is easier with a short term release cycle.
Job is done in summer. Integrated in official Blender in autumn. Feedback from official release is treated and bugfixed in winter. They can be proud of it and show it in spring.
That is way more easy for them to be invested in it than saying : “I worked a whole semester on that, this year. But that should be publicly acclaimed, at the beginning of next year.”
I am not talking about duplicate reports or anything like that. People are mostly using the official releases. That’s why most reports come in after an actual release. When there are fewer releases, with more changes, instead of having the reports spread out over more releases, they would only arrive twice.
Yes. Reports should be more massively created in a shorter period after a release.
So, because bugs will be collected more rapidly. I see that has an advantage.
Developers will make connections between similar problems more rapidly.
They will have more time to solve them, to think about them.
Most of them will be solved under less pressure, less questioning about which problem will pass the cut of the next release or not.
Nope. Working like that is really painful! If I remember correctly, that was one of the reasons why shorter release cycles were initially introduced (not just in Blender).
Imagine you are working on a new feature. It takes some time to get through the review process, then it gets included into the master branch. Now because the release just took place, the next one is going to be in 6 months. Now you have to wait 6 months before people are really going to try it out. Not only is the feedback loop regarding bugs extremely slow like that. It would make incremental improvements really painful.
1 Like
You know that there are users scrutinizing what is added to master, everyday.
There are developers meeting notes, shared almost every week about what has been added to master.
That is very rare. That something, implying usability changes, added to master will not be tested by interested users, immediately.
So, no. What you are describing does not correspond to reality. It may happen that after months of development in an experimental branch. People who tested the branch will not complain when stuff is added to master.
But if there is no complain, where is the problem ? Do something else ? Chill out a little bit after the process review. Play with your work and do some demos.
The developer will not completely forgot what he has done, 6 months ago.
6 months later, he would still be able to handle the feedback.
A feedback loop of several months is slow, anyways. If you are waiting 3 months for a reply, you can wait 6 months.
People interested in giving pertinent feedback to developers will test nightly builds and give a reply in the week a change is made.
That is stupid to expect developers to understand what you want if you only give them an hint once, every 3 months.
You choose one extreme situation of “feature having to wait for feedback” to disqualify @conantheblendarian’s complain about the other extreme “feature next to release date and not detected in time”.
Incremental improvements will concern big modules, long term features.
Improvements of small features will be more important, more in-depth and stop to look superficial.
They’ve changed the numbering scheme, and introduced LTS releases, but they’re still sticking to the usual 3-4ish month per update release schedule they’ve roughly followed since 2.5 came out.
The claim was that they are “rushing” towards 3.0. And I don’t see them doing it for the sake of it.
Now you are all over the place, picking everything and throwing it into a bucket and taking everything I write out of context. Not interested in a “discussion” like that.
Maybe they are, but it looks they’re doing so by just skipping over a few version numbers, rather than rushing development in general.
If some people find themselves overly concerned about it, they can just call the 3.0 release Blender 2.87.
1 Like
If their goal was to get 3.0 quickly, they could simply have skipped to 3.0 with the justification that major new functionality would be introduced, justifying the jump. The given argumentation doesn’t make sense to me.
Really, I think this whole concern with the numbers is picking at nits, and fretting over the fraying.
2 Likes
Sorry if I did not understand what you wrote.
But your conjecture of a developer disoriented by a longer release cycle sounds silly to me.
I just consider that less releases is less pressure and unproductive work for developers.
I think that users writing constructed critics about a developer design can give work for weeks or months.
But basic bug tracking to know if a step of feature is stable or not (Does it crash ? Is feature doing what is expected ? Is there something obviously broken ?), that has to be done, in the days, the commit has been published.
They are not rushing, anymore. Because we complained and it was obvious that Blender 3.0 would persist to have serious lacks. Blender 3.0 was postponed.
But that does not mean that there was no rush, during the past 2 years.
Until Blender 2.93, several features were incomplete, many were just a first milestone and several have an experimental design, status and some were postponed, several times.
That would be more correct to say that during those periods. Developers released current state of development, no matter what was the interest for users.
What was the point to deliver Geometry Nodes in 2.92, for the user, except to make a little bit of publicity about the feature.
What was the interest to release an incomplete Extrude Manifold tool ?
Releasing EEVEE with lots of known limitations in first 2.80. That had to do with an urgent need of feedback.
But several known limitations in following releases, were there ; just because Clément did not have time to deliver more.
Current master is still using BI procedural textures in a lot of places. I warned them about the issue before codequest.
There are limitations, everywhere. Not by design, just because that takes time to erase them, in certain cases.
In other cases, that is because they did not have time to treat feedback.
That has to do to the amplitude of tasks, implied by new design.
The goal was not to get number 3.0, quickly.
The goal was to communicate that work would be done, quickly.
So, that passed by announcement that “2.80 will be released in July”. But reality was in October.
Then, that passed by the idea that : “satisfying release will be released when it will be ready. But there is hope, next releasing is just few months, away.”
Then, discontent was calmed by announcement of LTS releases. And that announcement marked Blender 3.0 as the LTS release changing the game.
That is true that developers are not rushing the features. But from status of incompleteness of delivered features, I took the liberty to write that they rushed the releases, to sum-up the past 3 years to someone who just switch to 2.93, this year.
You do know that the core development team has tried multiple release timings, right? They’ve had short-cycle releases every two months and then switched over to long cycle releases. The current model is an outcome based on the team’s multiple years of experience doing test with release timing.
Every decision has its trade-offs. What we have now looks like it’s trying to strike a balance that captures the advantages of each type while minimizing the disadvantages.
TL;DR: based on prior experience, longer release cycles probably won’t give the help you’re imagining it will.
4 Likes
We could look at how LTS releases are working out to try to understand how short release cycle is working.
Someone could make nice looking graph out of what I will write but it’ll not be me.
Releases, dates and number of fixes
- 2.83.0. Released on June 3, 2020. First ever Blender LTS.
- 2.83.1. Released on June 25, 2020. 3 weeks after previous 2.83 LTS. 33 fixes.
- 2.83.2. Released on July 9, 2020. 2 weeks after previous one. 15 fixes.
- 2.83.3. Released on July 22, 2020. 2 weeks after previous one. 17 fixes.
- 2.83.4. Released on August 5, 2020. 2 weeks after previous one. 19 fixes.
- 2.83.5. Released on August 19, 2020. 2 weeks after previous one. 25 fixes.
- 2.90. Released August 31, 2020.
- 2.83.6. Released on September 9, 2020. 3 weeks after previous one and 1 week after 2.90. 30 fixes.
- 2.83.7. Released on September 30, 2020. 3 weeks after previous one. 9 fixes.
- 2.83.8. Released on October 21, 2020. 3 weeks after previous one. 16 fixes.
- 2.83.9. Released on November 11, 2020. 3 weeks after previous one. 13 fixes.
- 2.91. Released November 25, 2020
- 2.83.10. Released on December 09, 2020. 4 weeks after previous one and 2 weeks after 2.91. 9 fixes.
- 2.83.11. Skipped due to technical limitations in Windows Store.
- 2.83.12. Released on January 27, 2021. 7 weeks after previous 2.83 LTS and 2 months after 2.91. 10 fixes.
- 2.92. Released on February 25, 2021.
- 2.83.13. Released on March 10, 2021. 6 weeks after previous one. 9 fixes.
- 2.83.14. Released on May 12, 2021. 9 weeks after previous one. 8 fixes.
- 2.83.15. Released on May 20, 2021. 8 days after previous one. 1 fix.
- 2.93.0. Released on June 2, 2021.
- 2.83.16. Released on June 16, 2021. 4 weeks after previous one. 9 fixes.
- 2.93.1. Released on June 23, 2021. 3 weeks after previous 2.93 LTS. 19 fixes.
- 2.93.2. Released on August 04, 2021. 6 weeks after previous one. 51 fixes.
- 2.83.17. Released on August 11, 2021. 8 weeks after previous one. 8 fixes.
- 2.93.3. Released on August 18, 2021. 2 weeks after previous one. 22 fixes.
That stat is obviously skewed because of devs changed opinion of what should or should not be an LTS fix. What I could say about that in general:
- Non-LTS release does not affect .x LTS release much. That to say, new releases contain enough changes to “show” general users mostly new bugs, not 3 months old ones, and/or developers will prioritize new ones for a fix.
- After 6 months (2 releases, one is only recently released) LTS fixes are quite stable, something about 1 fix per week. So we could agree it’s definitely an upper bound to how long a release cycle should be.
Unfortunately that’s all I could think of. If someone have other thoughts, you’re more than welcome. 
Another thing to note is that we can assume 3.0 as a precedent of a longer release cycle. It’ll be like 5 months long. We have a chance to see how stable new features and release in general will be and compare to previous releases (if we will correctly remember them). It would be even better to hear triagers/developers opinion after like a month or so about number of bugs/reports compared to previous releases.
I remember a discussion about a release every two month for 2.8.
I don’t remember a period when that was the case.
I am following Blender since 2 decades. And since 2 decades, I think that release cycle is too fast for users.
Anyways, I think that past experience of anybody may be biased and invalidated by current situation.
There are a lot more developers, tasks to manage and members of community.
In the end, I was just highlighting misunderstanding of users like @conantheblendarian. Those who think that a release, tagged as LTS is guarantee of reliability.
But due to the context of Blender’s mutation, that is not really the case.
There is a need to explain why you may currently encounter limitations in many places in the software.