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<[email protected]> wrote: >>> In reply to Sergey I. Sharybin ([email protected]): >>> >>>> 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 >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
