Repository navigation
Release v0.8.0 #191
Description
Activity
Question (for those in the know): should the tag for this release be
0.8.0orv0.8.0? It seems like the latter is what I see for other packages, but not sure if that will mess up themake_version.pyscript and/or other infrastructure.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.
I typically create a tag locally for a release, push the tag to github, and then make the Github "release" based on the tag.
As for whether to name the tags
0.8.0orv0.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 uses0.8.0, while scikit-image and pytorch usev0.8.0. I would probably suggest sticking with 0.8.0, since that's what the last release used (long ago), and that's whatmake_version.pyassumes, but it is not a strong preference.Anything still blocking 0.8.0? Are we going to do a Slycot release first?
A couple of things I think we should do:
- Release slycot 0.3.2, containing the updated Travis CI build + updated README. This just requires doing a couple of the merges and then rebuilding via conda-forge.
- Review PR Fix namespace and logic errrors in statesp.freqresp + unit tests #196 and PR Fix margin() documentation to address issue #195 #198. It would be useful to have someone do a quick check on these just to make sure I didn't miss anything.
- 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.
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!
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.
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.3created on conda-forge.
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!).