[Bf-committers] Blender 2.59 release AHOY!

[Sergey I. Sharybin]

Hi,

I've got fix for grease pencil in mu branch [1], but it's really that 
kind of changes which shouldn't be applied in last minute (at least 
there are several possible issues i wanted to check), so let's limit GP 
a bit for 2.59.

About reloading scripts and so. I've been working on UI in my branch 
after merging ghash changes there and haven't found any bad sides of 
this change.

About more clear release next time. I'm not sure why this release is so 
"crazy". Is it our lag, lag of coordination or so..

[1] 
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=39313

P.S. linux 32/64 bit would be available soon.

Campbell Barton wrote:
> Hi, woke up to find a re-release from a revision that contains changes
> I made that were *not* intended to be in a stable release - switching
> operators and menus to hash lookups.
> We should have branched at r39259 stable and applied patches there
> before re-releasing.
>
>
> There is also the issue with grease pencil session - where the
> operator points to data that can be freed on 'Global Undo' (as opposed
> to the crasher with the modal operators own *fake* undo, fixed 39237
> and double undos fixed 39235).
>
> Sergey's fix means you can't move the viewport while grease pencil
> session is enable so the option is now not at all working as it was
> meant.
>
> *Sigh*
> Since there were 3 fairly bad bugs in this tool (2 crashers), my
> impression is that option isn't used all that much.
> A correct fix isn't some small edit, the operator must store data
> differently, this should have been picked up during normal
> development, IMHO we should not attempt to sort this out as a
> last-minute, show-stopper fix.
>
>
> There is the remaining issue:
> Do we use current bsd/linux/mac builds from r39304 (and wait on win
> build before announcing),
> Or re-branch from 39259 and apply a few fixes there and rebuild on all
> platforms.
>
> By not re-branching we break our own guidelines - to unfreeze quick
> but use a branch for fixes and it feels very sloppy to me.
> On the other hand my change of moving operators/menu's into a hash
> isn't that big a deal and works with scripts reloading, freeing,
> re-registering operators etc - I would expect any bugs here would be
> obvious and break blender immediately, so I *think* they are safe.
>
> Suggest to go ahead with r39304, but next release be more clear with
> release tag/branch, and the following unfreeze.
>
> - Campbell
>
> On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein<mein at cs.umn.edu>  wrote:
>> In reply to Sergey I. Sharybin (g.ulairi at gmail.com):
>>
>>> Didn't know OSX still have got issues with non-trunk verison. I've just
>>> commited patch from Jens to solve this problems.
>>>
>>> We prefer to keep revisions synced for all platforms, so please use
>>>
>>> Trunk: r39307
>>> Extensions: r2241
>>>
>> Updated tarball of the source and md5sum are in incoming on ftp.blender.org
>>
>> Kent
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>


-- 
With best regards, Sergey I. Sharybin