[Numpy-discussion] Should we make the master branch backward compatible.
mwwiebe at gmail.com
Fri Jan 28 18:37:20 EST 2011
Does anyone have any objections to me merging the branch into the numpy
trunk right now?
Chuck suggested I try to split out the ABI changes, but they're kind of
tangled with the other changes. In particular, they involve fixing the type
promotion code to be enum order-independent, which depended on some changes
done for the iterator buffering code. After the key ABI fixes, there are
then changes to a fair bit of code to make both numpy and scipy pass their
tests. Anyways, editing that history at all feels like a bit of a quagmire,
so I'd sooner just go ahead and do the merge.
On Fri, Jan 28, 2011 at 7:19 AM, Bruce Southey <bsouthey at gmail.com> wrote:
> On 01/27/2011 10:58 PM, David Cournapeau wrote:
> > On Fri, Jan 28, 2011 at 12:46 PM, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >> Hi All,
> >> Mark Wiebe has proposed making the master branch backward compatible
> >> 1.5. The argument for doing this is that 1) removing the new bits for
> >> releases is a chore as the refactor schedule slips and 2) the new ABI
> >> settled and keeping the current code in won't help with the merge. Mark
> >> thinks it is possible to keep the datetime types along with the new half
> >> types while restoring backward compatibility, and if so we won't lose
> >> anything by making the change. I'm in favor of this change, but I may
> >> overlooked something. Thoughts?
> > I would be in favor too, but having not being able to code much in
> > numpy the last few months, my opinion should not carry too much
> > weight. I don't know how many people install numpy from github
> > nowadays (which are the first "victims" when ABI breaks)
> > cheers,
> > David
> It is important to hear from people like Keith that build upon numpy and
> those that build numpy binaries for distribution especially Windows and
> non-gcc stuff like Intel's compilers and MKL.
> So while I do count less but I am in favor of it provided that scipy can
> build and run correctly with this new numpy.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion