[Bf-committers] Blender 2.59 release AHOY!

[pete larabell]

Just so I'm not confused as a platform builder... are the 39307 builds
ok, or are we building again? lol

On Fri, Aug 12, 2011 at 8:59 AM, Jim Williams <sphere1952 at gmail.com> wrote:
> As painful as this attitude seems, I'd have to agree with it.  The
> idea here is to modify expectations -- mostly on the developers part.
>
> Um....given that the next number is to be 6.0 I wouldn't mind seeing
> that "200 bugs" turn into "0 bugs" in the near future rather than have
> to learn new UI.  It's really nice when round numbers mean pretty
> product.
>
> On Fri, Aug 12, 2011 at 6:45 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> This issue (IMHO) is not worth holding back the release for, we can
>> review Sergey's fix and have it ready for next release.
>> We now have 200 bugs in the tracker, so unless new bugs are found that
>> are regressions from previous releases we're better off sticking to a
>> more strict release cycle, 2.59 release we have now fixes ~140 bugs
>> since 2.58 so IMHO users are still better off with the update and not
>> waiting longer.
>>
>> On Fri, Aug 12, 2011 at 8:22 PM, Jass <gaia.clary at machinimatrix.org> wrote:
>>> Why don't you just shift the release date (by one week for example),
>>> fix the issues as needed and keep trunk frozen for that period ?
>>> Wouldn't that help to get out an excellent release and avoid
>>> to push out 2.59b one week after 2.59 was released ?
>>>
>>> Am 12.08.2011 07:52, schrieb 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
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> No essence.  No permanence.  No perfection.  Only action.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>