[Bf-committers] Blender 2.59 release AHOY!

[Campbell Barton]

While writing my last reply I made an error checking on the re-release
revision I saw Sergey's mail refer to 39304.
In my last mail substitute 39304 with 39307.

Lets use tag's next time!

On Fri, Aug 12, 2011 at 10:30 AM, pete larabell <xgl.asyliax at gmail.com> wrote:
> 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
>>>>
>>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell