Repository navigation
Release final v1.2 #4395
Description
[edited by @astrofrog @taldcroft]
There was a list of issues in this issue that had been copied over from the 1.1 issue (#3519) but which also diverged from what we did for 1.2 in the end, so I've moved that to the wiki: https://github.com/astropy/astropy/wiki/Old-to-do-list-for-1.1
Instead, here are some feature pull requests that we might want to exceptionally consider backporting to the 1.2.x branch before the release (these should be considered by the coordination committee):
- Refinements/API changes for
AstrometricFrame- Make AstrometricFrame behave like other coordinate frames. #4941 - Example Gallery improvements - Minor improvements to mechanics of example gallery #4924
- Support for choosing different sources for planet positions - Solar system plan94 #4920 - @mhvk @StuartLittlefair @eteq
- fixed bugs in get_sun #4952 - this is a bug fix (there are other bug fixes not in this list because they are included by default), but is noted here because it is important for Solar system plan94 #4920 to actually get the right answers for some items. Note that First part of fix to get_sun #4979 needs to be backported first before fixed bugs in get_sun #4952 (it was originally one issue, but it turns out the changes in First part of fix to get_sun #4979 need to go to 1.0.x too, while the changes merged in fixed bugs in get_sun #4952 are 1.2.x, so it was split into two issues)
- Auto-downloading of IERS-A data - Implement auto-downloading of IERS-A data #4436 - @taldcroft @mhvk @eteq
Other to-dos for the release:
- Release and update astropy-helpers in astropy and package-template if needed
- Write 'what's new in 1.2'
- Do a v1.0.x release
- Clean up changelog - @astrofrog
- Update IERS B file (Final update of IERS B for 1.2 #4994)
- Backport any PRs milestoned as v1.2.0 merged after the feature freeze (mostly bug and documentation fixes, and maybe a couple of feature PRs from the list above)
- Update list of contributors
- Update stats on contributions in 'What's new'
- Update release tooling/instructions for latest procedures
One question is, do we actually bother doing another bugfix release in the v1.1.x branch, or do we just move those changelog entries to v1.2.0?
Activity
taldcroft commentedon May 16, 2016
Auto-downloading of IERS-A data #4436 is merged to master now.
astrofrog commentedon May 16, 2016
@taldcroft - isn't #4930 just a bug fix? (if so it doesn't need to be in the above list since it should be uncontroversially backported)
taldcroft commentedon May 16, 2016
@astrofrog - yes, you are correct, I have taken it out of the issue description above. It is merged now to master and milestoned for 1.0.10.
eteq commentedon May 16, 2016
What's the "Do an LTS release" release about, @taldcroft and @astrofrog ? (Or did I write that? I'm not sure since it's been edited...)
astrofrog commentedon May 16, 2016
@eteq - I updated the whole block of text and I don't think there's anything left from what you had (now in the wiki page). I thought it would probably make sense to do a new 1.0.x release at the same time as (or a bit before) 1.2.0?
astrofrog commentedon May 16, 2016
@eteq - I unticked the PRs you marked since we should only tick these once we've considered whether to backport them.
eteq commentedon May 16, 2016
Ohh, gotch @astrofrog - I was thinking #4436 was merged before the new release, but I now see it wasn't.
And I get it now - by "do an LTS" you meant 1.0.x. Yes, I agree that's a good idea at the same time as 1.2.
astrofrog commentedon May 16, 2016
@mhvk - I'm having issues backporting #4770 to v1.0.x and v1.1.x because, while it backports without conflicts, the tests don't pass afterwards. Since you are familiar with the units code (and this PR was from you), would you be happy to try and figure out what else needs to be backported for this to work?
[all other v1.0.x PRs have been backported otherwise, to v1.0.x and v1.1.x]
eteq commentedon May 16, 2016
Coordination committee agreed #4436 was a good backport to do because it was basically done before the freeze, just needed some rebase/cleanup (and is important to get in!)
mhvk commentedon May 17, 2016
@astrofrog - happy to help in principle, but I don't really know how to try things out myself. Do many tests fail, or just the ones added by 4770?
mhvk commentedon May 17, 2016
Could we add #4933 to the list? It updates IERS B to the latest version and also makes a correction to the
IERSAutocode that came up when we did that.astrofrog commentedon May 17, 2016
@mhvk - testing that locally is pretty easy - just fetch the latest upstream, then do:
Then run the tests. I can't remember exactly what test failed. Typically with this kind of issue, it means that there are other changes that we should be backporting that weren't milestoned as
v1.0.x. Alternatively, it could be the #4770 works properly only if we backported new features, in which case we should not backport #4770.If you figure it out, don't push to v1.0.x yet - post your finding here and we can decide on the best way to proceed.
mhvk commentedon May 17, 2016
That gives conflicts... I'm running out of time here, so will focus on #4933 first.
32 remaining items
taldcroft commentedon Jun 17, 2016
👍 on #5106
taldcroft commentedon Jun 17, 2016
What about #5111 to add an IERS-specific remote timeout? I'm a little worried that some people will have slow networks or whatever and end up getting needlessly confused. But it is obviously not critical.
astrofrog commentedon Jun 18, 2016
I'm fine with including #5111 - @eteq what do you think?
astrofrog commentedon Jun 18, 2016
@eteq - everything so far is backported except #5111
I think there have been no issues related to astropy-helpers reported, so I think I can go ahead with the final 1.2 release of the helpers, right? (and since it hasn't changed, no need to do the whole 'open a PR to check' etc?)
mhvk commentedon Jun 18, 2016
@astrofrog - I'm not sure whether this is related to astropy-helpers, or an issue with
conda, but when I tried updatingastropy-helpersand the template to 1.2rc1 in mybasebandproject yesterday, I got some weird travis errors (see https://travis-ci.org/mhvk/baseband/builds/138469982). In particularNUMPY_VERSION=stableseems to have downloaded numpy 1.5 in two occasions (and for numpy 1.9, I also get failures that weren't there before, possibly because it uses astropy 1.0.1 -- I haven't had time to investigate).As said, though, I'm not sure this is related to astropy helpers -- and it is difficult to check since the python 3.5 tests started to fail without the update (
ConfigParserissue).astrofrog commentedon Jun 18, 2016
@mhvk - don't think this is due to astropy-helpers - if anything it could be an issue with conda, and we should check what ci-helpers is doing there.
bsipocz commentedon Jun 18, 2016
If you say "stable", then ci-helpers will install the one that comes up
from conda without any version restrictions. This worked reasonably well
until the recent changes in conda, etc.
For astropy started to fix this behaviour, but the solution is far from
being optimal, so no PR yet.
Numpy 1.9 builds are failing in many packages because of the 1.0.1 astropy
version that comes with it.
On 18 June 2016 at 16:55, Thomas Robitaille [email protected]
wrote:
mhvk commentedon Jun 18, 2016
@bsipocz - OK, good to hear that it is not my package only! I'm wondering if for my package at least I'm better off forgoing conda altogether, as they seem to have rather a lot of growing pains on their road to, effectively, a distribution package manager (and seem to be reinventing wheels in the process). It may be safer to just get packages from different Debian version repositories -- those are more guaranteed to not change from under me...
astrofrog commentedon Jun 18, 2016
I don't really understand what's been happening with conda recently - it worked perfectly fine last year... But I wonder whether it would make sense to just pin conda to an old (working) version and keep it there until things have sorted themselves out.
eteq commentedon Jun 18, 2016
👍 on backporting #5111
eteq commentedon Jun 18, 2016
And yes re: doing a final 1.2 release of the helpers, @astrofrog
eteq commentedon Jun 19, 2016
I think once #5119 is in, we are ready for final release, @astrofrog!
astrofrog commentedon Jun 19, 2016
Release done! 🎉
Pull request to update website: astropy/astropy.github.com#108
We should wait for the package to be updated in the default conda channel to announce
eteq commentedon Jun 20, 2016
Since the release is done, I am closing this (but will create a new one for 1.3).
Nice work all, especially @astrofrog for cranking through the release this time around!