python 3.5 is out too.... Is it possible to move the "main" tests to python3.4, including doc build & coverage?

@eteq - I'll try and dig out the Numpy 1.6 stats later this week.

@eteq - the AppVeyor build can be updated from 2.6 to 2.7

I'd like to keep Numpy 1.6 testing for now but would be happy to move toward deprecating support for it.

Ah, good point on py 3.x additions, @mhvk . Although that makes me even more inclined to drop numpy 1.6 so as to reduce our test load... (Will wait on making changes until @astrofrog reports back re the numpy 1.6 stats)

If need be we could drop general testing against Numpy 1.6. But we should continue supporting it at least through 1.2, (even if marked deprecated), and so there should be a note somewhere to test against Numpy 1.6 before making any releases until support is officially fully dropped...

Amongst astronomers:

@eteq - just to be sure, I meant to replace the python2 documentation, coverage, pep8, numpy-dev tests with python3 ones (and arguably also replace the mac-os one with python3), so that shouldn't lead to additional test load (though adding python3.5 obviously does).

Still some 1.6 users around. If we raise a deprecation warning when astropy is used with Numpy 1.6 that will probably also motivate the 1.6 users to get their upgrades going :)

I agree, let's deprecate Numpy 1.6 in 1.1 and remove in 1.2

Regarding 3.5 - if we test with 3.3 and 3.5, do we need 3.4?

If you really want to deprecate numpy 1.6 with almost as many users as numpy 1.7 - and 5% is quite a few depending on astrofrogs sample size - why not deprecate both of them? This is just a question to satisfy my curiosity not meant seriously.

Should have 3.4. In fact should have 3.4 over 3.3 probably. Preferably all 3 though.

@MSeifert04 has a good point. There are a number of workarounds we can also drop if we deprecate support for Numpy 1.7 as well. I suppose one could argue that the combined total of 1.6 and 1.7 is a more significant slice of the population, but even that number has probably gone down since that survey was taken...

Just to add a sort of heuristic data point, the last two LTS releases of Ubuntu are 14.04 and 12.04. Ubuntu LTSs are supported for 3 years for desktop users and 5 years for server users. The Numpy package in 12.04 is v1.6.1. For desktop users that support has already ended (yikes, time flies!) For server users it's supported until 2017. Astropy v1.0 (which supports Numpy 1.6--in fact it's the minimum version) came out February 2015, and as an LTS of Astropy will be supported according to APE-2 "at least" until February 2017. So technically there's a two month gap were an Astropy that works on Ubuntu 12.04 wouldn't be supported while Ubuntu 12.04 is still supported. However, APE-2 is deliberately flexible--the words "at least" are deliberate. In the very remote chance someone needed extended support for a little while they could get it. (I'm also not saying there's any reason Astropy LTSs have to track with Ubuntu LTSs--I'm just using it as a reference point).

Meanwhile, the Numpy version in the most recent Ubuntu LTS, 14.04, is Numpy v1.8.1. So deprecating support for Numpy 1.7 would have little impact in that regard.

It would seem reasonable not to support numpy 1.6 and 1.7 for our next long-term support version, and to assume that anybody who can install astropy >=1.2 can also install a more recent version of numpy.

That said, we could also follow a more simplistic scheme, where we just follow what scipy and/or matplotlib do. Both seem to support numpy >=1.6 as of now.

@eteq - this will need rebasing following the ci-helpers change

@eteq - this will need a rebase. Can you send an email to the astropy-dev list to ask if there are any objections to removing support for 1.6 and 1.7? (noting that the bug fix releases for 1.0 and 1.1 will continue to support those versions).

I'm not sure if this is appropriate to bring up here, but I am wandering if it would not be good to include testing on different scipy versions as well. Unless I am reading the .travis.yml file wrong, I do not believe there are any travis tests that include a scipy install.

Although this is not currently a dependency of astropy, it is imported roughly ~30x in the package and I could imagine things could start breaking if we aren't regularly checking that those tests aren't failing (or maybe they have been failing and we just haven't been checking them). Scipy is at least used in the stats, cosmology, modeling and convolution packages.

Another question for a different thread would be whether scipy should just be made a dependancy.

@crawfordsm - any test that includes $CONDA_ALL_DEPENDENCIES does include scipy, so we are testing it in some configurations. However, it's a valid question as to whether we should test different versions.

@astrofrog ah thanks!

@crawfordsm I think it would make the test matrix too expansive to test against different scipy versions as well. (And even if we did I would maybe want to test only the tests that explicitly require scipy.)

It would be nice if we had some Jenkins instances to run more expansive tests again, but someone has to maintain that which becomes time consuming (which is why we stopped doing it).

Just as a reminder: do move the sphinx, pep8, coverage, and numpy-dev tests to python 3.4 or 3.5 instead of python 2.7 (in preparation for #4454)

Up: Python 2.6 was removed, but Numpy 1.6 is still there and bothers me for #4776.
(and Numpy 1.11 is out, so 1.10 should be added to the list of old versions to test)
I think everybody here agree that Numpy 1.6 (and 1.7 ?) support can be remove in Astropy 1.2 ?

@saimn - no objections from me, now that 1.11 is out, we'd still be supporting the last 4 versions.

This needs rebasing.

@pllim - Actually this PR could be closed: Python 2.6 was removed, and the default numpy version was changed to stable. I am preparing another one to remove Numpy 1.6 & 1.7 and the compatibility code.

@eteq , can you confirm that it is okay to close this?