My opinion is that we create a (short-lived) branch for the release, and continue development (ignoring the release) on master.
If CyFunction solves no problems that blocks a release, I am -1 on merging it into the release branch. But we shouldn't keep things in pull requests just because we're waiting for a release, it is better to use a dedicated release branch. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. mark florisson <markflorisso...@gmail.com> wrote: On 30 July 2011 11:55, Vitja Makarov <vitja.maka...@gmail.com> wrote: > 2011/7/30 Stefan Behnel <stefan...@behnel.de>: >> Hi, >> >> I wonder what we should do with Vitja's CyFunction branch. He mentioned >> issues with it in the past (I remember that there was one specific changeset >> that he considered questionable), and it seems that we found several ways to >> extend the function support beyond that, which may have an impact on the >> current way it's implemented. >> >> Is this something that makes sense to be included in 0.15, or should it wait >> to get stable and further extended before being merged? >> >> It appears to me that there are reasons for one and the other. However, >> given that we plan to drop support for (at least) Python 2.3 after this >> release, I feel that we should try to get out a version that doesn't require >> much fixing and maintenance. Changing the implementation of functions at >> this point seems like a rather deep cut. If we agree that it's in a state >> that we feel comfortable with, I wouldn't object to merging it. Otherwise, >> I'd suggest to wait until after the release. >> >> Comments? >> > > That's not such a big change, CyFunction replcaces old > PyCFunction_binding type and shouldn't break anything. > > > -- > vitja. >_____________________________________________ > cython-devel mailing list > cython-devel@python.org > > http://mail.python.org/mailman/listinfo/cython-devel > +1 on merging, I think > it's been ready for weeks. I see no problem if it passes the testsuite, and I > need it for fused types (although admittedly I'm taking a vacation after this > weekend)._____________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
