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.asyl...@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.asyl...@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.asyl...@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 <ideasma...@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 <m...@cs.umn.edu> wrote: >>>>> In reply to Sergey I. Sharybin (g.ula...@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@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> >>>> >>>> >>>> -- >>>> - Campbell >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers