For a most stable and usable Blender.

General Forums Blender and CG Discussions
1

Devs are still fixing bugs like mad exterminators since the 2.63 release to this day. Maybe their aim is to not let the bug tracker reports pile up as it happened not so long ago ? Noble effort.
Nevertheless, the users still do complain that 2.63 is less stable and usable than previous versions. This is strange given the exceptional testing and bug squashing that happened during the months before its release. Let’s accept that as a fact though to move the discussion forward.

The traditional solution has been to have a bugfix release soon after. Doesn’t seem to happen this time so I guess that 2.63 is judged fairly good. Still I was wondering… would it be possible to have the many fixes introduced post-release and that apply to 2.63 poured in a branch where none of the new stuff (and the unavoidable bugs that come with it) would be included and possibly interfere? In the long run, this branch could lead to one hyperstable version, comparable to the legendary 2.49b.

Such stability would put Blender far ahead of others like Maya and Max on that account. I could use such a tool in my professional work. There’s nothing worse than bugs when making a presentation for clients.

What do you think? Is this desirable? Is it even feasible?

2

That is a known fact in software development. Maintaining one designated software version with bug fixes and potentially back ports, while at the same time proceed with development is a strain on the recourses. In my professional career I never programmed software that maintained such stable releases, never the less there are examples. However if you look closely these projects have large companies (Oracle, Microsoft, Canonical) or a huge community behind them. In the Open Source realm it seems customary, to proceed with the next release, since you have always the possibility to compile from the sources where the bugs are fixed. This approach may not be very user friendly, however the Blender community is much better of than others. There are the nightly builds provided by the Blender Foundation and we have a great source of compiled versions over at graphicall.
Taking a look at your proposal, it can be done, however there is a price to pay:

  • Every dev (that I know) prefers to implement new features over fixing bugs. So forcing devs to spent time fixing/backporting bugfixes for stable (long term) releases might shy them away. Most of the work is done on a voluntary basis. The invest their time because they like doing it. Taking the fun out of the work might not be such a good idea
  • Redistributing resources available to maintain a long term release hinders the development of new features, which means either they won’t come at all or later. I suppose we also would see fewer releases again.
  • Of course we could hire more recourses, but they want to be paid.

If you yourself are willing to invest in one of these three options, go ahead and buckle down. On the other hand I will just say it is always easier to find something that is not as you imagine it should be, than to do something about it.

3

Between 2 official releases, to get a more bugfixed and up to date (in term of svn) Blender you can always download a nearly daily released build on the buildbot :
http://builder.blender.org/download/

They’re build from the latest source code (and so include all the bugfixes since “stable” 2.63) and do not include experimental changes or features like the builds you can find graphicall

On the bug tracker the devs have been working really hard, the amount of bugs they fixed daily is impressive.
But again people that experiment crashes and problem should really take some of their time and report those on the bug tracker :
http://projects.blender.org/tracker/index.php?group_id=9&atid=498&power_query=1&query_id=35&run=Power+Query
And of course explain how to reproduce the problem they experienced (providing a .blend when it’s complex is always another good way to help the fixing).

If some crashes that are obtained in specific conditions are not reported, chances to see them fixed one day are very low.
And if the bug you report is in fact a feature or a limitation, you’ll have a dev telling you about it.

The only problem with the bug tracker is that for unknown reason some people are unable to reach it.
I had lot of trouble myself until someone told me that to log in, i needed to type my username only in lower case characters by example.

But still, if you can , try to report the problems you experienced and give the devs the most hints possible on reproducing it.

4

I hope you remember that Blender just had a major system overhaul. It’s like a complete refresh.

Maybe 2.63 release is one of the riskiest release. But it is a release that the developers had to make in order for the software to move forward into the future.

I think it is fair to complain about stability after Blender 2.65 but not while we are in 2.63 and 2.64.

5

Interesting… Buildbot says “Warning: these builds are not as stable as releases, use at your own risk.”

What happens to these builds? I see they are all revisions of 2.63 but will code from these eventually make it into a 2.63a release?

I’ll admit the whole version / revision / branch methodology has always confused me. I was under the impression that these revisions don’t only consist of bugfixes, so they can introduce regressions and new problems as well.

From the public perspective of blender.org, if all that users see to download are major releases and not bugfix releases, they will always be getting a “mostly stable” blender due to all the merges that go with a release.

Not trying to complain, just want to figure out how the release philosophy works :wink:

6

Nearly each day the source code is updated with bug fixes (and sometime new functions), and each day the buildbot get the source code and compile a version of Blender.
I would say that most of the buildbot builds are actually more stable than the “stable” blender, featuring bug fixes for problems that were in the “stable” release.

Only when the source code gets updated with something big and new (like when the Bmesh merge was done on the 2.62 source code) , the buildbot builds may be considered less stable, as what is big and new is usually going to be buggy.

The addon section of those builds has lots of addons not available by default in “stable” Blender (the ones you can download manually usually), they’re in the “Testing” category though so you don’t enable them by mistake if you don’t want to test them.

But other than that, usually the buildbot versions of Blender are solid and most time, more stable than the “stable” release due to the bug fixes of problem the “stable” releases had.

7

no features, no stability :(((

8

So if what I’m gathering is correct, “For a most stable and usable Blender” you would have to get a
revision somewhere between 2.63 and 2.64 and hope that the bugs that were fixed didn’t coincide with a merge or update at that point in time (that could break other things).

I know an LTS version of Blender is impractical, but official Blender releases don’t happen that often. After a release couldn’t we just spend some time over a week to get a “2.63a”? The past few releases we haven’t seen bugfix releases and it’s a bit strange that we are left to gamble and dig through revisions instead.

I really commend the efforts of the developers in squashing so many bugs, but it seems that sometimes their efforts are offset by only being available in (possibly buggy) new revisions and not official bugfix releases.

9

After a release couldn’t we just spend some time over a week to get a “2.63a”? The past few releases we haven’t seen bugfix releases and it’s a bit strange that we are left to gamble and dig through revisions instead.
The idea is not to have an ‘a’ release, only if there if there is a critical bug found just after the oficial release. This is only as good as users putting in effort testing the release candidates and feeding back bugs. If you want a stable release it’s up to you and me and every other user making an effort.

10

Fair enough, but there is also an influx of downloads when the official version is released, so a certain amount of bugs only get found a short while after release. Relying only on release candidates as a bug benchmark ignores the nature of the general downloading public, does it not?

As I said, the bugfixes happening in the revisions are great, but don’t you think it would make those efforts from the developers even more rewarding if they could be added to an “a” release for a little period after an official release? It would serve to make the official Blender more stable and only reflect well on Blenders popularity and usefulness.

Perhaps I’m being too demanding, I understand many volunteer their time and resources to the betterment of Blender, but I’m discussing this with exactly same the intentions in mind :wink:

11

2.49 IS blender LTS

12

That’s the one we’ll recommend for the new users… Anything in 3D will be simple after learning that… ;D

13

I understand the need for a more conservative bugfix-only “LTS” release, but even though it seems like Blender has a ton of developers with its current pace, there’s no one who has the time/motivation to maintain such a release. I think currently the ‘a’ releases is as close as we get, and even those are not something to expect (if they were, would most production people wait for that only to find bugs warranting a ‘b’ release?)

I think someday we will see a maintainer for a stable version, like we have for Linux. With more popularity and developers, someone might take the role and responsibility (ideally endorsed by the BF), maybe someone from a larger studio as part of the job? Again like with Linux, as Blender hits critical mass it will be worth it for someone to pay for a maintainer. Until then…

14

To be honest I find the 2.6.3 buildbot (daily-) builds to be VERY stable (and MinGW builds to be very fast)… Earlier I just took the latest ‘fastest’ build of Graphicall.org and sometimes they just were really unstable, hehe… Buildbot is better. For now at least… :slight_smile:

15

@ Holtz

That is a known fact in software development. Maintaining one designated software version with bug fixes and potentially back ports, while at the same time proceed with development is a strain on the recourses.

In my ignorance I thought that, since bugs are fixed any way, it could be as simple as committing the fixes to two branches, ‘trunk’ as we have already and another one where no new features, only applicable bug fixes would be admitted. I guess that what you are saying is that fixes for the same bug aren’t the same for an evolving branch like ‘trunk’ than they would be for a ‘no new feature’ branch ?

the possibility to compile from the sources where the bugs are fixed.

I watch what’s committed daily and build almost every day too. Although the bug fixes that I wish to see in a ever more stable official version are in those daily builds, more bug are created by committing new code. Stability is never insured, as it is only reasonable to expect. I’ve had to keep two SVN three, building them alternatively, in case one build just won’t succeed. I made a small script to save files and re-open them right away in case the file becomes unreadable. I have autosave saving every minute two minutes so it is easy to run Blender in debug mode with the file that caused the problem. Right now Campbell, Sergey, Brecht and a few others like Bastien, Nicholas… seem to keep a close watch on the bug tracker and are even fixi stuff that they notice by themselves. We’ll see: after all they also have other duties.

Redistributing resources available to maintain a long term release

I wasn’t thinking of something as involved as an LTS: just fixes for bugs that are done anyway and no new features.

If you yourself are willing to invest in one of these three options, go ahead and buckle down.

I am learning to code: slow process. For the moment my (maybe too lofty) goal is to create an environment for artisan furniture and renovation shops where the metaphor would be closer to the practice of the trade. One thing for sure: I’ll fix my own bugs. :smiley:

@ Sanctuary

and do not include experimental changes or features like the builds you can find graphicall

Still, the code that gets committed is usually not thoroughly tested and hence more buggy than that of any official release.

On the bug tracker the devs have been working really hard, the amount of bugs they fixed daily is impressive.

Simply breathtaking. :slight_smile:

But still, if you can , try to report the problems you experienced and give the devs the most hints possible on reproducing it.

You can read in my response to Holtz all I do to report bugs.

@temujin143

I think it is fair to complain about stability after Blender 2.65 but not while we are in 2.63 and 2.64.

I think that you are right on that. Nevertheless, asking around if there doesn’t exist one fairly simple way to enhance the final stability of each version != complaining.

@ ParticleXY

What happens to these builds? I see they are all revisions of 2.63 but will code from these eventually make it into a 2.63a release?

AFAIK they are builds of the trunk not pure revisions of the last official release, which is exactly what I’d like to see and very subject of this thread. The include new code destined to the next version of Blender with its own lot of bugs hence the ‘less stable’ warning.

Not trying to complain, just want to figure out how the release philosophy works :wink:

So am I, exactly: making my education.

I really commend the efforts of the developers in squashing so many bugs, but it seems that sometimes their efforts are offset by only being available in (possibly buggy) new revisions and not official bugfix releases.

Wise words IMHO.

Fair enough, but there is also an influx of downloads when the official version is released, so a certain amount of bugs only get found a short while after release. Relying only on release candidates as a bug benchmark ignores the nature of the general downloading public, does it not?

Your observation is again quite right: Blender get its most thorough testing from the day of the official release on. The common response to that is that is the responsibility of the users to test the RCs. This is unfair to many. Firstly I have a feeling that Blender has more quality users with each passing day who are responsible for more bug reports than ever. Secondly it is not everyone who can afford the risk that RCs present while racing to meet the deadlines.

@abc123

I would say that most of the buildbot builds are actually more stable than the “stable” blender, featuring bug fixes for problems that were in the “stable” release.

That’s been my experience too. The problem is that when new features or even new code breaks some part of Blender it is usually in some entirely unexpected way and sometimes in apparently totally unrelated areas, parts that may have always worked just fine foe you. This is hard to anticipate, can be costly, although it is risk that can be minimized by taking a number of precautions.

@san

I understand the need for a more conservative bugfix-only “LTS” release, but even though it seems like Blender has a ton of developers with its current pace, there’s no one who has the time/motivation to maintain such a release.

Again, I wasn’t thinking of an LTS: just applying the fixes to the official version until the next one gets released.

16

OK, what about this: could the bug fixes be made available as patches for the current official version?
Would there be too much work involved in the preparation of such patches?

17

It’s still how it goes. 2.63 hasn’t been out for very long. An ‘a’ release was talked about in the last meeting. The decision is to be determined at this Sunday’s Meeting.

I think people get jumpy about Blender as far as bugs go just because we can see how the sausage is made. It typically has an impressively low number. Maya is so infamous for crashing, I’ve even seen meme’s made about it on Reddit.

18

LOL - I don’t remember a time when it did, ever… But then of course I don’t push it to the max, I don’t script a.s.o… But saying Blender is stable in comparison to Maya, that just isn’t true on any level, hehe… ;D

But it’s a known fact that you can mess up Maya as well as Nuke (which is also amazingly stabile) with Python (and MEL) scripting, but then the fault is the coder, not the application. And I bet this is as true for Blender as Maya or Nuke…

19

After reading through a number of Maya threads over the years, I can almost say for sure you have lucked out here (though as a disclaimer; I will say that I have never used Maya).

Technically, when you look at the total number of bug reports on projects.blender.org, you’ll find a significantly lower number of active bug reports in the 2.6x series than 2.49, something which has been consistent over the past few releases.

Some people would like to blame the shorter release cycle for any perceived increase in instability, but conversely we are actually seeing a lot more bugs being fixed than before because many are being found earlier than they would otherwise. You might argue that this is being offset by the large and more frequent influx of new features and rewrites, that might actually be true to an extent in some releases, but the bugs relating to the new stuff are also be fixed in quick succession.

20

@Ace

I know why 3D apps crash and I don’t do much of that, import complex meshes or scenes, I seldom do complex (or interacting) sims, advanced particle systems, scripting a.s.o… I mosty just model, do materials, texturing, lighting & then render, all that in one app, then render out & composite and/or do post work on stills in another (mostly AE or PS). It is an insanely stabile workflow, that’s why I do it like that, hehe… As simple as possible.

But when you start to do complex animation, sims, fluid dynamics & scripting, I don’t think it matter much which app you use, they all have the potential to break, especially when having sims interacting or doing bad scripting, hehe… But when I do such things, not often I do, but when I do, I always break it down to a level where I do it piece by piece thus minimizing the crash potential…

On the other hand I’ve worked a lot with stressed out people who take workflow risks/shortcuts, and that also makes for a more crash-prone workflow… :stuck_out_tongue: