[Bf-committers] Roadmap 2.5 proposal
ideasman42 at gmail.com
Sun Sep 20 08:44:02 CEST 2009
While I dislike quibbling over version numbers and probably wont
change Ton's mind but calling this 2.5 seems a mistake to me.
- "So we call it 2.5 and then have to explain to people its not quite ready"
Why do this?
Why not call it 2.5 pr1, 2.5 pr2, That or beta1, beta2 etc.
preview release, beta, even RC (while incorrect) communicates better
this is something to test seriously but not fully wokring.
not suggesting everything from 2.4x should be back before 2.5.0m but
at least have durian artists test a bit and use in production so a lot
of the basic bugs and features are worked out.
- barely working repayable macros
- fairly unstable apis, (some stuff in the rna/python API's is just temporary)
- keymaps - will these be final for 2.5.0 ?
- External render api threads crash frequently.
- BGE isn't working and may well not be working properly for 2.5.0,
some stupid small things, but noticeable like removing logic links.
- Python scripts in background mode not well tested, not useful, no
operators for eg.
I suspect Ton uses this so devs get their arses kicked by users after
2.5.0 release which will motivate them to get stuff working fastest...
this has a way of working but makes me reticent to care about user
complaints from such a premature release.
On Sat, Sep 19, 2009 at 7:07 AM, William Reynish <billrey at me.com> wrote:
> Hi Ton,
> I think this sounds like a good plan, but at the same time it's
> important that we make it clear that 2.50 is not a production ready
> release. It's good to get wider testing, but it's also dangerous to
> promote 2.50 as being stable and complete if it isn't. It sounds like
> 2.50 is intended to be a sort of beta release (feature complete but
> buggy), which is fine, but we should makes the clear to users.
> On 19 Sep, 2009, at 3:42 PM, Ton Roosendaal wrote:
>> Hi all,
>> A rough big picture for the next 11 months I've put in this schedule:
>> Some notes to understand the basics behind the proposed schedule:
>> Durian lasts either 6.5 or 9 months... we only know this early
>> november. It means that some of our film development targets can shift
>> a bit.
>> I've split the development targets basically in these steps:
>> 2.5 0: Get back at least what worked in 2.4x
>> (with clear exceptions, like py im/export scripts)
>> 2.5 1: Wrap up what's minimal required for 2.5
>> (Make a feasible pick of all things we need now, and what to do
>> This then should be the (first) version usable for docs or books.
>> All of the other new development projects (bmesh, render, etc) move to
>> after this deadline, which we define in three intermediate release
>> steps, for example:
>> 2.5 2: BMesh, modeling projects
>> 2.5 3: Animation features
>> 2.5 4: Render/composite features
>> Which (not coincidentally!) aligns with the durian project anyway. To
>> celebrate a succesful Durian film we can then move to a 2.6 version in
>> the summer after, which also should wrap up and complete all 2.5
>> projects and expectations.
>> I also propose to officially make this a "2.5 series" of releases, and
>> work towards a 2.6 version with release codes 2.5.0, 2.5.1 etc. Not
>> very important... but probably communicates better.
>> Finally I propose to accept we do more releases this year... whatever
>> we name them, 'test binaries' or 'upgrades' or 'candidates'. Making
>> more official builds will help us a lot.
>> This schedule is nice topic for discussion here, online and in the
>> meeting tomorrow. Will then summarize all feedback in an updated
>> I'll also then like to know all the other developer targets and
>> predictions... like for the game engine, dynamics, video, sound, etc
>> Ton Roosendaal Blender Foundation ton at blender.org
>> Blender Institute Entrepotdok 57A 1018AD Amsterdam The
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers