[Bf-committers] Blender 2.59 release AHOY!

Jass gaia.clary at machinimatrix.org
Fri Aug 12 12:22:15 CEST 2011


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
>>>
>>
>



More information about the Bf-committers mailing list