[Bf-committers] Render Branch Plans
ideasman42 at gmail.com
Wed Aug 11 08:40:41 CEST 2010
Hi Brecht, think you know my opinion on the topic but since you didn't
get a reply yet may as well post.
*Disclaimer that I dont know render internals*
My impression is that the render branch is reasonably stable in terms
of crashing, but breaks compatibility in areas, some of these areas we
didn't use for Durian so perhaps there are cases which users complain
Breaking compatibility I think we can cope with and merge soon - just
needs to be documented. Stability is not so simple if you merge in
bugs in not-well-tested code that can become really problematic later
on (especially if you aren't available so much for render bug fixes).
I remember minor changes I made in trunk could somethings conflict
with the render branch and its nice to be able to look into a bug
report without having to check the render branch to see if it still
applies there, but these are fairly minor.
Bottom line is you and Ton should decide since you will be the ones
Assuming the problems are more about compatibility then stability:
+1 for a merge soon.
On Fri, Aug 6, 2010 at 11:12 PM, Brecht Van Lommel <brecht at blender.org> wrote:
> Hi all,
> I've written some docs on the render branch changes, more coming:
> I'll also release a patch for the new shading nodes, however they are
> only in a prototype stage and far from finished. There's no clear plan
> yet for when to merge the render branch changes (and I couldn't really
> discuss it properly yet before the Octane announcement). There's a few
> * Merge as soon as possible, so it ends up in 2.6. This means the
> changes then would be available immediately, disadvantage is that we
> make trunk more unstable, and have to break render compatibility
> twice, assuming a new shading refactor happens in a following release.
> * Merge after the 2.6 release. This means it will take a bit longer,
> but not get in the way of current bugfixing work to get a release out.
> Does most likely mean breaking render compatibility twice.
> * Merge along with a shading nodes refactor. It's unknown when this
> would be done, and I can't be involved with it much. Means everything
> can be changed at once and tested better.
> I looked into merging only "safe" changes that would not break
> compatibility much, but this seems to be very difficult, so I can't
> see other options. My personal preference would be to merge things
> after 2.6, maybe at that time others may be interested / have the time
> to improve things further.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers