[Bf-committers] Blender 2.59 release AHOY!

pete larabell xgl.asyliax at gmail.com
Fri Aug 12 02:30:22 CEST 2011


well, 12.5 hrs from now... is tomorrow for me. i can have it uploaded
in 13hrs from now.

On Thu, Aug 11, 2011 at 7:29 PM, pete larabell <xgl.asyliax at gmail.com> wrote:
> if you need 39304 for FreeBSD it'll have to wait till tomorrow... :(
>
> On Thu, Aug 11, 2011 at 7:29 PM, pete larabell <xgl.asyliax at gmail.com> wrote:
>> I only have a 39307 uploaded.. don't think I put 39304 up... is 39307 ok???
>>
>> On Thu, Aug 11, 2011 at 7:10 PM, Campbell Barton <ideasman42 at gmail.com> 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
>>>>
>>>
>>>
>>>
>>> --
>>> - Campbell
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>


More information about the Bf-committers mailing list