[Numpy-discussion] NumPy 1.7 release delays
ralf.gommers at googlemail.com
Tue Jun 26 15:48:44 EDT 2012
On Tue, Jun 26, 2012 at 9:20 PM, Travis Oliphant <travis at continuum.io>wrote:
> On Jun 26, 2012, at 2:10 PM, Ralf Gommers wrote:
> On Tue, Jun 26, 2012 at 5:43 PM, Travis Oliphant <travis at continuum.io>wrote:
>> Hey all,
>> After some more investigation, I'm not optimistic that we will be able to
>> get a 1.7 release out before SciPy. I would like to get a beta release
>> out by SciPy (or even an rc1 release). But, given the number of code
>> changes and differences between 1.5.x and 1.7, I think we will need an
>> extended beta release stage for 1.7 that will allow as many users as
>> possible to try out the new code base and report back any regressions or
>> backward incompatibilities that need to be fixed before the final release.
>> The fundamental rule I think we have is that "code depending on NumPy
>> that worked with 1.5.x should continue to work with 1.7 without alterations
>> required by the user"
> The rule should be 1.6.x imho. Undoing things that were changed in between
> 1.5.x and 1.6.x makes very little sense; numpy 1.6.0 has been out for over
> a year.
> Unfortunately, I think there are issues we are just now seeing with code
> that was released in 1.6.x, and there are many people who have not moved
> forward to 1.6.x yet.
Some examples would be nice. A lot of people did move already. And I
haven't seen reports of those that tried and got stuck. Also, Debian and
Python(x, y) have 1.6.2, EPD has 1.6.1.
I think the number of cases we're talking about here is in fact limited.
But discussion of those cases is necessary if a change would break 1.6.x.
The rule should in fact be that code working with NumPy 1.0 should work
> with 1.7 (except for "bug-fixes").
That's a good rule. Hard to ensure for corner cases which didn't have test
I realize that with some of the semantics it's going to be hard to be
> pedantic about the "rule". But, I'm going to be very responsive to users
> of 1.5.x and even possibly 1.3.x who have code issues in trying to move
>> This does not mean we can't add new APIs or deprecate old APIs --- but I
>> think that we do have to be much more careful about when deprecated APIs
>> become unavailable. There is a lot of code that assumes the current
>> API. Both code that is in released packages and code that is in
>> "unreleased packages" which we are not even aware of.
> I think you are mainly talking here about changes that had unintended
> side-effects, and broke things without anyone realizing that in time. If
> you read the 1.5.0, 1.6.0 and 1.7.0 release notes, there have been very few
> actual deprecations.
> Besides that, we have a long standing policy of removing those things that
> do get deprecated after one minor release:
> http://projects.scipy.org/numpy/wiki/ApiDeprecation. If you propose to
> change that, I suggest discussing it in a separate thread.
> We need to change that, I think. I feel pretty strongly that we can't
> just remove APIs after one minor release after observing more of NumPy's
> use in the wild. APIs should exist for at least 5 years and preferably
> only change on major releases.
>> I don't want to finalize the 1.7 release until we get enough feedback
>> from end-users about the impact of all the changes. This will likely take
>> a longer beta-release period than usual: certainly not until after SciPy
>> where we will make a concerted effort to get people to try the new 1.7 beta
>> and report back on the impact on their code-base.
>> Ondrej is helping out on this effort which I really appreciate. Other
>> people who have time to help with the release effort --- especially in
>> fixing regressions will be greatly appreciated.
> Did you happen to see
> Among other things, it lists a few things that are still to be done (merge
> doc wiki edits, flip the "raise_warnings" switch) and details on the Wine /
> MinGW setup that may be useful. I did just spot a mistake there by the way,
> we're still on MinGW 3.4.5.
> It's nice to have a document like this. Of course, I've seen it. I
> don't think we will be using Wine and MinGW to do the Windows builds,
Any more details? If you are thinking about using MSVC for numpy, will it
work with existing scipy and other binaries?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion