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 v0.8.0 #191

Closed
murrayrm opened this issue Feb 5, 2018 · 11 comments
Closed

Release v0.8.0 #191

murrayrm opened this issue Feb 5, 2018 · 11 comments
Assignees
Milestone

Comments

@murrayrm
Copy link
Member

murrayrm commented Feb 5, 2018

This issue is intended to track the release of version 0.8.0 of the python-control toolbox. All of the changes that go along with this release are now done, so I am planning to use this issue to track the steps in actually getting the release out the door (since the last time we did one was a couple of years back!).

I've put an outline of what I think the steps are for generating a release on the wiki under release instructions. Will start working through those and post progress here. (I'm going to be doing this off and on in the coming week or so => might take a while to get things out the door. If anyone wants to help, just let me know!).

@murrayrm murrayrm self-assigned this Feb 5, 2018
@murrayrm murrayrm added this to the 0.8.0 milestone Feb 5, 2018
@murrayrm
Copy link
Member Author

murrayrm commented Feb 5, 2018

Question (for those in the know): should the tag for this release be 0.8.0 or v0.8.0? It seems like the latter is what I see for other packages, but not sure if that will mess up the make_version.py script and/or other infrastructure.

@murrayrm
Copy link
Member Author

murrayrm commented Feb 5, 2018

Another question: how does it work to use the github releases mechanism. If I create a new release on github, does it automatically create an annotated tag? Or should I create the tag by hand (once I figure out what to call it) and then create the release using the tag? The github documentation on releases is pretty sparse.

@moorepants
Copy link

moorepants commented Feb 5, 2018

I typically create a tag locally for a release, push the tag to github, and then make the Github "release" based on the tag.

@cwrowley
Copy link
Contributor

cwrowley commented Feb 5, 2018

As for whether to name the tags 0.8.0 or v0.8.0, I don't think it makes much difference, though of course it would be good to pick something and be consistent. For instance, it looks like scikit-learn uses 0.8.0, while scikit-image and pytorch use v0.8.0. I would probably suggest sticking with 0.8.0, since that's what the last release used (long ago), and that's what make_version.py assumes, but it is not a strong preference.

@roryyorke
Copy link
Contributor

Anything still blocking 0.8.0? Are we going to do a Slycot release first?

@murrayrm
Copy link
Member Author

A couple of things I think we should do:

@repagh
Copy link
Member

repagh commented Jun 24, 2018

OK, I just checked some things locally.

For the new slycot version, PR Slycot/#24 and Slycot/#25 seem to be compatible, Slycot tests with Slycot/#25 are OK with openblas. I propose using the openblas 0.3.0 from conda-forge, since that is available across the board for Mac OSX, Windows and Linux.

Slycot/#22 probably needs a small update, we need to add a remark that for anaconda installs people should use the conda-supplied compiler, instead of installing/using external compilers.

With that, these three PR's can be merged,

As for python control, we have the combined Slycot/control issue with the Travis build failures. I think the combination of Slycot/#25 and #206 fixes that. That takes a leap of faith, since the checks are failing, but I think it is better to forge ahead and fix things, than to spend our time on finding a path that leads to clean Tavis builds and checks.

What do you think?

p.s. sorry for picking the wrong button!

@repagh repagh closed this as completed Jun 24, 2018
@repagh repagh reopened this Jun 24, 2018
@murrayrm
Copy link
Member Author

Slycot v0.3.3 is now completed, so moving on to next steps:

  • Review open issues and tag any that should be resolved in v0.8.0 release
  • Review open pull requests and tag any that should be integrated into v0.8.0 release
  • Create the 0.8.0 tag on python-control. Once that is done, we can start rolling out the changes on conda-forge, readthedocs, etc using the (proposed) release instructions.

@murrayrm
Copy link
Member Author

murrayrm commented Jul 2, 2018

I've merged all of the PR's that I think belong in version 0.8.0, so I think this version is pretty much ready for release. The last remaining item (I think) is to have slycot 0.3.3 created on conda-forge.

@murrayrm
Copy link
Member Author

murrayrm commented Jul 6, 2018

Slycot 0.3.3 how available via PyPI (pip) and conda-forge. However, there is some discrepancy between the two versions, as described in issue #217.

@murrayrm
Copy link
Member Author

murrayrm commented Jul 7, 2018

Issue #217 resolved in PR #220. Starting to work on final release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants