[Numpy-discussion] NumPy 1.7 release delays

Ralf Gommers ralf.gommers@googlemail....
Tue Jun 26 14:48:44 CDT 2012


On Tue, Jun 26, 2012 at 9:20 PM, Travis Oliphant <travis@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@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.
>>
>
> +1
>
>
>> 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
coverage though.

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
> forward.
>
>
>
>> 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
> https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt?
> 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,
> though.
>

Any more details? If you are thinking about using MSVC for numpy, will it
work with existing scipy and other binaries?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120626/b6fc328d/attachment.html 


More information about the NumPy-Discussion mailing list