[Numpy-discussion] Numpy 1.11.0b2 released

[Julian Taylor]

On 01/30/2016 06:27 PM, Ralf Gommers wrote:
> 
> 
> On Fri, Jan 29, 2016 at 11:39 PM, Nathaniel Smith <njs at pobox.com
> <mailto:njs at pobox.com>> wrote:
> 
>     It occurs to me that the best solution might be to put together a
>     .travis.yml for the release branches that does: "for pkg in
>     IMPORTANT_PACKAGES: pip install $pkg; python -c 'import pkg;
>     pkg.test()'"
>     This might not be viable right now, but will be made more viable if
>     pypi starts allowing official Linux wheels, which looks likely to
>     happen before 1.12... (see PEP 513)
> 
>     On Jan 29, 2016 9:46 AM, "Andreas Mueller" <t3kcit at gmail.com
>     <mailto:t3kcit at gmail.com>> wrote:
>     >
>     > Is this the point when scikit-learn should build against it?
> 
>     Yes please!
> 
>     > Or do we wait for an RC?
> 
>     This is still all in flux, but I think we might actually want a rule
>     that says it can't become an RC until after we've tested
>     scikit-learn (and a list of similarly prominent packages). On the
>     theory that RC means "we think this is actually good enough to
>     release" :-). OTOH I'm not sure the alpha/beta/RC distinction is
>     very helpful; maybe they should all just be betas.
> 
>     > Also, we need a scipy build against it. Who does that?
> 
>     Like Julian says, it shouldn't be necessary. In fact using old
>     builds of scipy and scikit-learn is even better than rebuilding
>     them, because it tests numpy's ABI compatibility -- if you find you
>     *have* to rebuild something then we *definitely* want to know that.
> 
>     > Our continuous integration doesn't usually build scipy or numpy, so it will be a bit tricky to add to our config.
>     > Would you run our master tests? [did we ever finish this discussion?]
> 
>     We didn't, and probably should... :-)
> 
> Why would that be necessary if scikit-learn simply tests pre-releases of
> numpy as you suggested earlier in the thread (with --pre)?
> 
> There's also https://github.com/MacPython/scipy-stack-osx-testing by the
> way, which could have scikit-learn and scikit-image added to it.
> 
> That's two options that are imho both better than adding more workload
> for the numpy release manager. Also from a principled point of view,
> packages should test with new versions of their dependencies, not the
> other way around.


It would be nice but its not realistic, I doubt most upstreams that are
not themselves major downstreams are even subscribed to this list.

Testing or delegating testing of least our major downstreams should be
the job of the release manager.
Thus I also disagree with our more frequent releases. It puts too much
porting and testing effort on our downstreams and it gets infeaseble for
a volunteer release manager to handle.
I fear by doing this we will end up in an situation where more
downstreams put upper bounds on their supported numpy releases like e.g.
astropy already did.
This has bad consequences like the subclass breaking of linspace that
should have been caught month ago but was not because upstreams were
discouraging users from upgrading numpy because they could not keep up
with porting.