Release final 1.0 version

[astrofrog]

For now, I have copied over some of the 'high-level' to-dos from the 0.4 checklist that were not done. We should brainstorm on which of these we want to keep, and what other high-level features we want for 1.0.

Integration of units:

• Improve integration of Table columns and quantities (Support Quantity, Time, and Coordinates in Table objects #664, When instantiating coordinates from a table column with units, use the units #1762; possible implementation in Supporting ndarray subclasses in table columns #1839) - @astrofrog @taldcroft @embray @mhvk
• Improve integration of Table columns with Time and Coordinate objects (Support Quantity, Time, and Coordinates in Table objects #664; sample implementations Proof of concept for Table mixins - Time and FunctionColumn #1833 and Table with generalized columns #1835) - @taldcroft @mhvk
• Implement masked quantities (Implement MaskedQuantity #1852) - @adrn @mhvk

Coordinates, Time, and Observatories:

• fully implement IAU 2000 trasnformation stack for ICRS -> AltAz @eteq @mhvk
• automate IERS updates (Automate updating IERS_B and LeapSecond files whenever a release is made #1697) and other data with expiration dates. @mhvk @taldcroft @eteq
• barycentric coordinates and velocities, ideally at VLBI precision (if things go quickly enough)

Stabilize modeling API:

• implement support for Quantities(Models should support Quantity #1464) @nden @embray @wkerzendorf
• implement composite models (including fitting) (Support fitting of composite models #1054) @nden @embray @wkerzendorf
• implement custom_model_2d (Implement custom_model_2d #1763) @embray (really the goal here is just custom_model ND)
• add 'default_fitter', 'last_fitter' and 'fit' method to models (Add a fit method to models #1330, Store fitter object in model object #979) @nden @embray @wkerzendorf
• add support for getting uncertainties on parameters (Add support for returning uncertainties on fit parameters in astropy.modeling #1827)

Miscellaneous:

• Implement any backward-incompatible API changes needed for the future generalized WCS (even if the full thing isn't implemented) - @nden @perrygreenfield @jehturner

In addition, the following documentation/help-related issues should be addressed:

• Implement a help system tied to exceptions/warnings - @demetri

Lower priority issues

• Better integration of FITS tables and VO tables with the Table class - @mdboom @taldcroft @embray

[jehturner]

First misc. item: We discussed the co-ordinates API with Erik and he made a few organizational changes. I think we didn't foresee further changes to the existing package for generalized WCS, but the latter is probably not well enough developed to be sure. It might be a good idea to keep this on the list any wider implications get considered properly?

[astrofrog]

@jehturner - actually this point refers more to making changes to astropy.wcs that would make it backward-compatible, rather than astropy.coordinates

[astrofrog]

@eteq @embray - weren't we supposed to include a list of packages that will actually be supported as LTS? (or maybe easier would be to mention packages that won't be supported?). There is a LTS section in the whatsnew, so that would be a good place to mention it.

[astrofrog]

Do any of the entries in the stability page need to be updated?

[eteq]

@astrofrog - I was thinking the stability page serves for that purpose. I don't think we wanted to make specific guarantees beyond whatever is there, right? We can definitely update the LTS description to point to the stability page, though.

[astrofrog]

@eteq - so just to clarify, my point was that in the current 'what's new' we say This means v1.0 will be supported with bug fixes for 2 years from its release - the question is, in 1.5 years, if the modeling API has changed a lot for example (hopefully it won't, but just as an example), fixing bugs may be more effort than just backporting, because there might be bugs in the old API that don't exist in the new API (so we have to fix bugs in two APIs independently). Of course we agreed to the LTS so to some extent we have committed to the extra level of effort, but on a previous telecon we had discussed that for sub-packages that may still evolve a lot, we would not guarantee to fix all bugs, especially in API-unstable packages. But I think that most sub-packages are now pretty stable in Astropy, so maybe the issue is moot.

Basically what I'm suggesting is that we could say we will not necessarily fix all bugs in gray or yellow subpackages in the stability page in the LTS if the API evolves significantly in 1.1, etc.

[perrygreenfield]

Yes, I thought we had agreed that there may be subpackages that may not get LTS support if relatively new.

[astrofrog]

So once we merge #3459, at the moment the following sub-packages would be considered not stable yet:

• analytic functions
• io.misc (in a way, what's there now is mostly stable, it's just in might grow over time)
• modeling
• stats (again, what's there at the moment is kind of stable)
• utils (same, what's there is stable, but might grow)
• visualization
• vo (could be upgraded to stable since it's been in since 0.4)

So really, we're only talking about maybe not supporting full bug fixes to analytic_functions, modeling, and visualization, but the rest is probably pretty stable.

[wkerzendorf]

I would put NDData on that list - the new version has not been in any
release as of yet.

On Mon Feb 09 2015 at 1:47:04 PM Thomas Robitaille notifications@github.com
wrote:

So once we merge #3459 #3459, at
the moment the following sub-packages would be considered not stable yet:

• analytic functions
• io.misc (in a way, what's there now is mostly stable, it's just in
  might grow over time)
• modeling
• stats (again, what's there at the moment is kind of stable)
• utils (same, what's there is stable, but might grow)
• visualization
• vo (could be upgraded to stable since it's been in since 0.4)

So really, we're only talking about maybe not supporting full bug fixes to
analytic_functions, modeling, and visualization, but the rest is probably
pretty stable.

—
Reply to this email directly or view it on GitHub
#2758 (comment).

[pllim]

vo.client and vo.validator are stable in the sense that I don't have time to work on it. Is vo.samp also stable?

[pllim]

No, wait, wait... I notice that vo still use ConfigAlias. I don't think we should label it as stable until it switches to new config system for realz. What do you think, @mdboom ?

[mdboom]

@pllim: Any uses of ConfigAlias will already raise deprecation warnings, so aren't considered part of the current API. And the new config API is already in place. So I don't think this should be marked as having an unstable API.

[pllim]

Okay, thanks!

[eteq]

See #3469 for an addition to what's new that points readers to the stability document to know what they can expect LTS for.

[astrofrog]

@eteq - I think we are ready for RC2, there are no more PRs for 1.0

[eteq]

I missed the window ;) now #3474 needs to finish testing, and we should decide if #3389 goes in 1.0. After that I'll cut an RC.

[eteq]

Note that I added a wiki page at https://github.com/astropy/astropy/wiki/v1.0-RC-testing to allow people to report testing results and announced with the RC2 release. (we'll see if anyone actually uses it...)

[astrofrog]

I think we are good to go apart from #3512 and #3458. All remaining issues from the RCs are non-critical as far as I can see.

[astrofrog]

@embray - I think we are all set to go, and #3515 (updating astropy-helpers) is passing. Can you go ahead and release astropy-helpers 1.0? Then I'm happy to try and do the final 1.0 release for astropy since I have some time this week (unless you wanted to do it).

[embray]

Perhaps we should take all the unchecked check boxes on this issue and move them to a "Release final 1.1 version"? :)

[astrofrog]

@embray - will do it now

[astrofrog]

Unaddressed issues moved to #3519

[astrofrog]

@embray - are we good to go for the release? Shall I give it a try?

Important note: once the release is done I will ping the conda folk to make sure they create a new package before we announce it, so that we can advertise conda as an installation/update method. We need to prepare the announcements anyway.

[jehturner]

FYI, we also intend to release a new Ureka (1.5) with it after a couple of weeks of further testing.

[embray]

@astrofrog If you'd like to do it that's fine. I'm also happy to do it. I think as long as we're coordinated on the fact that this is going to happen imminently (so that the proper website updates and announcements can go out concurrently...)

[astrofrog]

@embray - ok, if you are happy to do it in the next few hours, then please do it and I'll work on making sure the website and announcements are ready. If you don't have time in the next few hours let me know and I'll do it.

But importantly, once the tar file is ready and on PyPI, we should wait until tomorrow to announce it, to allow the conda people to build a conda package, so we should not send out any emails to astropy or astropy-dev. I'll also update MacPorts.

[embray]

@astrofrog So are you saying we should or should not upload it to PyPI? Or are you saying that for typical users having it on PyPI won't affect them anyways?

[astrofrog]

We should upload it to PyPI now.

If anyone happens to pip install between now and the announcement, then it's fine. But we don't want to put out the big announcement, have everyone who is using anaconda use pip to update because it will mess things up in future. So it's just the announcement that needs to wait for a day after the tar file is on PyPI, so that we can mention 'conda update astropy' as a possible update mechanism.

[astrofrog]

Just for info, changes to the website including announcement are here: astropy/astropy.github.com#51

[zblz]

I see that the 1.0 conda binary package is already available for numpy 1.9, but for 1.8, 1.7, and 1.6 the conda package is an older version (0.4.1, 0.4.0, and 0.4.0, respectively). Do you know if astropy will be updated for all numpy versions? It would be really useful for travis testing, otherwise it is impossible to test features that require astropy>=1.0 with older numpy.

[astrofrog]

@zblz - I'm currently working on building precisely what you ask :) We have our own conda channel (https://binstar.org/astropy-ci-extras) for this and I've just launched the builds for astropy 0.3, 0.4, and 1.0 (the repo used to build these is https://github.com/astropy/conda-builder). More soon.

[astrofrog]

@zblz - basically, once these packages are ready you should do e.g.

conda install -c astropy-ci-extras numpy=1.6 astropy=1.0

[zblz]

@astrofrog - Thanks!

[astrofrog]

@zblz - some of the files have started to appear so you can start testing this if you like:

https://binstar.org/astropy-ci-extras/astropy/files

[zblz]

The ones that have appeared (1.7 and 1.6) are working fine: https://travis-ci.org/zblz/naima/jobs/51348825
Edit: And 1.8 - Thanks!

[astrofrog]

@zblz - I think all the linux packages are done. Are there any missing for your purposes?

[zblz]

@astrofrog - No, everything is working. Thanks again!

[embray]

That reminds me, I also need to post wheels for Windows to PyPI.

[mhvk]

This can be closed! Yay!