Repository navigation
Release v0.8.0 #191
Description
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!).
Activity
murrayrm commentedon Feb 5, 2018
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.murrayrm commentedon 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 commentedon 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 commentedon Feb 5, 2018
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.roryyorke commentedon Mar 11, 2018
Anything still blocking 0.8.0? Are we going to do a Slycot release first?
murrayrm commentedon Mar 11, 2018
A couple of things I think we should do:
python-controlOnce that is done, we can start rolling out the changes on conda-forge, readthedocs, etc using the (proposed) release instructions.
repagh commentedon 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!
murrayrm commentedon Jun 30, 2018
Slycot v0.3.3 is now completed, so moving on to next steps:
python-control. Once that is done, we can start rolling out the changes on conda-forge, readthedocs, etc using the (proposed) release instructions.murrayrm commentedon 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.3created on conda-forge.murrayrm commentedon 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 commentedon Jul 7, 2018
Issue #217 resolved in PR #220. Starting to work on final release.