With the release cycle for 2.6x being discussed, what do you think is the best way?

I ask because I’ve seen this on the mailing list.
http://lists.blender.org/pipermail/bf-committers/2011-August/033078.html

Others generally agree, though Campbell stresses that the eight week cycle should be kept, replies later on might spark an impression of concern that an eight week release cycle will ‘GIMP’ Blender and erase any future it has in serious CG work.

So I would ask, what does the community think would be a release cycle that offers the best balance of features and stability, I personally think that the minimum time that should be allowed for a release cycle would be at least three months, adding flexibility to delay the release if there’s any additional time needed to fix serious bugs or major issues with new tools.

Now some might think that a rigid approach would force discipline among the primary developers, but why do that anyway, you don’t have the ideals of a cooperation where deadlines is money and missing it means financial loss for investors. By all means a nonprofit like the Blender foundation has nothing to lose if delaying the release is needed and would likely result in happier users and growth in the number of users and developers.

So the question is, what release schedule would provide the best balance of fixes, features, and stability?

i dont see why cycles wasnt included in the last release of Blender as an Alternative.

Yes, keep blender internal as the default, but get cycles out in the wild. just my opinion.
(in the drop down menu where you choose what renderer engine you want to use,
for cycles maybe put a little disclaimer “beta” and a version # next to cycles or something…)

As I understand it, the two months period is only for merge work. Larger project work still takes place in branches on its own schedule. And if after 4 or 6 months they decide the period is too short then there’s nothing stopping them from changing it. Let them try it, maybe it will work out.

Well, there’s a number of things I would think would need to be taken into account with how much work on new features is done in trunk vs. branches when giving your opinions and ideas, development of such a large piece of software is anything but a simple task.

Would the best way forward be to give every developer who creates a patch a branch and let their changes appear in the commit log, if yes, then wouldn’t that saturate the list with patch changes and make it harder to check up on changes to the trunk?

Would there be a duality system where there’s a branch that all new features go into first and then go into the release branch when it’s ready and stable, would that mean code confusion if bits of multiple features are intertwined in one area of code?

Or is there a need for a more radical idea like this idea of mine which I question if the Fusion Forge software would even support it or if it’s worth the risk and the time for the Blender Foundation to try. Overhaul the patch tracker to where if you submit a patch, you have the option to auto-create a branch just for your patch so you can keep working on it to improve the quality of it (essentially replacing the long list of attachments saying 1.diff, 2.diff, ect… There would also be a personal commit log which tracks your commits to your patch that would not be connected to the main list as not to clog it with that type of work and of course the needed option to merge in all changes from trunk since the revision you started at to make sure it works with the latest revisions.

Then on top of that, an option to optionally combine branches covering multiple patches you have made or as a collaboration with other developers working on something similar. The final thing would be a switch that would indicate whether it’s still WIP or ready to review, and if reviewed and accepted would lead to the personal branch being merged into trunk, there’s always the question on how people who build Blender would be able to incorporate multiple patches as a result, an idea could be that the changes made to the branch could output to a master .diff file containing every change compared to the revision the branch was generated from.

I think a official release every 4 months is useful, because everybody can get the latest versions on graphicall.org .
Also it is very important to have a really stable tested versions !

Nobody needs to wait for the official version. For plugin and script developers it is very important to have stable releases.
I have seen the plugin problem in many projects and it is horrible. Best examples are firefox and chrome. Both are now very unstable and have huge plugin problems. This are huge companies with huge dev teams. For a small dev team like blender it is even more difficult to create a stable version.

There are many, many great scripts for blender that are not continued anymore because too many
releases and changes in the API. Script developers most times have the time to update their
script.

As a script developer a release circle of 4 month is great.

I think 2 months is a correct development cycle to include a massive amount of stable features into trunk but it is not a correct release cycles for scripters, book makers and blender’s teaching.
IMHO, best solution is to include two development cycles into one release cycle.
And maybe create midterm and final testing events like features challenges, splashscreen contest for development followers.
We might create best snapshots or demo’s contests to use pictures and videos in wiki or siggraph booth.

Why is it important what community thinks about release cycles ? No offense but I think users should stick to just making feature request and pray that a developer will actually bother.

The whole release schedules are a bunch of non sense if you ask me. Bugs don’t care about release schedule, you cant say to a bug “hey bug the release date approaches why dont you just debug yourself and call it a day ?” How many example we got of software that is rushed to a release just in the name of a on time release , to make it a awful release.

I am a python developer working on my lowly Blender addons and I would not dare to tell those developers to hurry up or stick to the schedules cause I know it works on theory and is torture on practice.

If you ask me I rather have smiling developers than smiling users. Of course I dont blame the usesr, they have the right to be frustrated when a feature is advertised to find it out it is long delayed and even vaporware. Nothing wrong with being organised, but if you are wise you always have a backup plan.

How long should a release cycle be ? As long it takes to create a pleasant and useful experience for the user. That’s my opinion.

Well,
we use that release cycle now for quite some time, and it works for us, the developers. :slight_smile:
Don’t worry about it and just enjoy the frequent releases.

Just be careful about burnout!

@kilon: Look at projects that have used this approach like GIMP or Hurd. No set release date means no pressure, and no pressure means little if anything gets done. It’s better to miss a release date than not to have one. IMHO.

I really don’t care about the frequency of new releases as long as it doesn’t bother developers.

Really ? Because last time I checked GIMP was the de facto open source image editor and nothing else can come even close. No bad at all for a no pressure application. Sure I like to complain about its GUI sometimes, it sucks not doubt about it, it can certainly use some love , but then Blender 2.49 GUI was not even better either.

Also visiting

http://www.ohloh.net/p/gimp

http://www.ohloh.net/p/blender

Clearly shows that GIMP has 1/2th and 1/3th of the devs that blender has , so comparing the two is pretty much pointless. Planning is all good but its there to impress your clients, not to be useful to developers. A developer know that there will be delays , expect that there will be delay, and people that want to stick to plans ussally sacrifice other things. Take blender 2.57 , a rushed , immature release that was crashing like crazy on my computer , I would not mind waiting for a few months to iron out those bugs.

I disagree with the tactic of rushing to a schedule and giving promises that you cant fullfil, finish first , speak later. We all can wait.

But some people care about features alot more than stability. Its a matter of taste, I am a person that like to create with no limations , rules and regulations. But my point was that users should not be making decisions on code design matters and schedules.

Gimp 2.6 was released in October 2008. I’m still using it. Even assuming they put out 2.8 in the next few months, do you think 4 years is a good release cycle? Don’t get me wrong, I’m thankful that they’re doing it, but I still think they could use just a bit of planning.

GIMP uses this thing now. GIMP typically has release targets, they just missed them repeatedly during the 2.7/2.8 cycle due to being really understaffed. Of course an argument could be made that they lack contributors due to the way they manage things.

Versions means nothing and definetely it does not take them 4 years for new release. What it matter is the feature set, ease of use and compatibility part. To tell you the truth I dont believe in plans. That does not mean I dont believe in organisation. I think a coder needs to be flexible and think on their feet as soon as a problem arises. The more experienced you become as coder the more you can be reliable in the way you work. I dont think 2.8 will be released in the next few month quite the contrary they just finished 2.6 and 2.7 is still WIP and by the wording in their website its shows that 2.8 is still long way to go. Porting a whole up from gtk2 to a gtk3 and such a major app as GIMP is no small feat.

I can relate to what you are saying but I dont think it matters that much cause its a 2d app its not as demanding as a 3d app where technology moves rapidly and either you follow along or you die old and forgotten.

The pressure on blender is 100 times more than on GIMP. For me as a painter GIMP already offers all I need, while blender yesterday got a feature I needed and used since 2002 , ngons. The only thing I need as a user from GIMP is a better more stable, more native GUI for macos, thats all.

So I think GIMP can certainly afford to be alot more laid back. But even with blender I think bmesh clearly shows why plans are there to fail and its not just bmesh, unlimited clay anyone, custom nodes and an army of others . Thats how software works , you dont tell it when it will be ready it tells you when it will be ready :wink:

GIMP 2.6 came out in 2008 this is 2012 assuming GIMP 2.8 comes out this year that would be 4 years give or take a few months no?

wait … wait … wait…

(kilon takes out his calculator)

correct !

Yeah… And the people at the FSF have been poking at Hurd since 1984 and they still don’t have a stable release :smiley:

I wish Gimp was as succesful as Blender…
It would be awesome to see GIMP be as good or better then PS… But it’s not even close, and the developments is so slow…

that’s true specialy last years photoshop start using massive algorytms.