Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v2.0 #94

Closed
cdeil opened this issue Aug 4, 2016 · 16 comments
Closed

Release v2.0 #94

cdeil opened this issue Aug 4, 2016 · 16 comments
Assignees
Labels
Milestone

Comments

@cdeil
Copy link
Member

cdeil commented Aug 4, 2016

FYI: I've added a v2.0 milestone and removed the v1.3 milestone.

My suggestion would be that we release v1.2 now, and reserve backward-incompatible changes to a v2.0 release, to be done in ~ 1 month.

There's many issues currently under the v2.0 milestone, but some of the key proposed changes that would justify a major version bump would be changes that are silently and sometimes slightly backward-incompatible like #89 or #35.

Another goal of 2.0 I think should be to get rid of the bundled Kapteyn like @sargas already attempted in #54 , so that pyregion can easily be packaged by Debian and others (they have to remove bundled files, it's not allowed).

@leejjoon , all - Sounds like a plan? Thoughts?

@cdeil cdeil added the question label Aug 4, 2016
@cdeil cdeil added this to the 2.0 milestone Aug 4, 2016
@cdeil cdeil self-assigned this Aug 4, 2016
@leejjoon
Copy link
Contributor

leejjoon commented Aug 6, 2016

Sounds good to me.

@cdeil
Copy link
Member Author

cdeil commented Sep 5, 2016

I've set the pyregion 2.0 milestone / release data to October 6.
If someone wants to do the release (@sargas?) please comment here.
Otherwise I can do it, it doesn't take much time.

The main change to use Astropy instead of Kapteyn was done by @sargas in #100.

Everyone - Please see https://github.com/astropy/pyregion/milestone/4 and help resolve those issues / review the PRs, or file new ones now if you think something should be changed for version 2.0.

IMO we should take this as our one chance to do all breaking changes (even if minor, like changing a function parameter name for consistency) and then (hopefully) keep the package stable again for the coming years.

We already have a few breaking changes:
http://pyregion.readthedocs.io/en/latest/changelog.html#unreleased
although they should be reflected more clearly in the changelog at least in this case:
#97 (comment)
where results can change with the update without getting a warning / error.

@astrofrog
Copy link
Member

Just a ping - it would be great to release 2.0 as pyregion 1.2 is broken with Numpy 1.11 due to some of the kapteyn code (which has been removed in master):

       """
>      lon = d2r( n.asarray(longlat[:,0],'d').flatten(1) )
E      SystemError: <built-in method flatten of numpy.ndarray object at 0x12b3b38f0> returned a result with an error set

/Users/tom/miniconda3/envs/dev/lib/python3.6/site-packages/pyregion/extern/kapteyn_celestial.py:117: SystemError

@cdeil
Copy link
Member Author

cdeil commented May 9, 2017

@astrofrog - Agreed.

I'll do the the pyregions 2.0 release for next week Thursday (May 18):
https://github.com/astropy/pyregion/milestone/4

@astrofrog
Copy link
Member

@cdeil - just to check, do you still plan on doing the 2.0 release?

@cdeil
Copy link
Member Author

cdeil commented Aug 3, 2017

There's still some open issues under the 2.0 milestone ( https://github.com/astropy/pyregion/milestone/4 ) but maybe I should just merge #113 and go ahead and make a release now? I'll ping on #65 once more asking if anyone has the expertise and time to have a closer look and resolve it soon.

@cdeil
Copy link
Member Author

cdeil commented Oct 14, 2017

I've made the 2.0 release: https://pypi.org/project/pyregion/

Can someone please try it out?

@bsipocz - do you have time to do this update?
https://github.com/conda-forge/pyregion-feedstock
Or should I give it a try? Is it just a matter of editing meta.yaml and making a PR?

@cdeil
Copy link
Member Author

cdeil commented Oct 14, 2017

Tag is also there: https://github.com/astropy/pyregion/releases/tag/2.0

@cdeil
Copy link
Member Author

cdeil commented Oct 14, 2017

Docs build is also OK: http://pyregion.readthedocs.io/en/2.0/

@bsipocz
Copy link
Member

bsipocz commented Oct 14, 2017

@cdeil - Thanks for making the release!
I can do the conda update if you like, normally it's super easy, only the version number and sha hash need to be updated.

@cdeil
Copy link
Member Author

cdeil commented Oct 16, 2017

Draft for pyregion 2.0 release announcement email:
https://gist.github.com/cdeil/c5f58f4398fb47403b49d5c6f60bf25b
(I'll wait for the conda packages to become available, just wrote it now for review)

@astrofrog or anyone - Thoughts?

@astrofrog
Copy link
Member

Looks good!

@cdeil
Copy link
Member Author

cdeil commented Oct 17, 2017

I tried the conda package on Mac. There's this warning:

software/anaconda3/anaconda3/lib/python3.6/site-packages/pyregion/tests/test_get_mask.py::test_region
  /Users/deil/software/anaconda3/anaconda3/lib/python3.6/importlib/_bootstrap.py:205: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
    return f(*args, **kwds)

But all tests pass, so I'm assuming all is OK. If someone thinks this needs to be looked into, please open a new issue.

Release announced on astropy and astropy-dev mailling lists:

@epaell
Copy link

epaell commented Nov 2, 2017

Just a note that there appears to be an incompatible change that causes aplpy (1.1.1) to fail when using the 2.0 version of pyregion. I've submitted an issue with aplpy (aplpy/aplpy#369) but I haven't fully debugged the issue to work out why it occurs.

@boada
Copy link

boada commented Nov 7, 2017

I'm experiencing the same issue as @epaell. I gave some more details in aplpy/aplpy#369.

@cdeil
Copy link
Member Author

cdeil commented Apr 30, 2018

I'm closing this old issue; it was about discussing the v2.0 release, which went out last year and then I forgot to close here.

@epaell @boada - for v2.0 there was some rewrite to use Astropy internally, and it looks like that has broken something for WCS with more than two axes. I see #66 is still open and seems very much related, please either comment there, or file a new issue.

@cdeil cdeil closed this as completed Apr 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants