Repository navigation
Release 0.8.4 and 0.9.0 sequencing #451
Description
Activity
Tried adding @bnavigator to this issue, but not showing up on the list. Mentioning here instead.
Reacted by Ben Greiner@sawyerbfuller goes by a different handle now?
#438 includes a merge strategy and resolves conflicts for the PR's it depends on, if you want to take that as a guide. The PR itself is thus only suited for >=0.9.0
Also, there is #431 (comment)
hi Richard, i lost control of the blinkminster GitHub account when I lost my caltech email address. Any idea how I can mark pr's with a milestone?
I can add your new account as a developer (and remove the old one).
Reacted by Sawyer FullerOK, you should now have developer privileges @sawyerbfuller. Let me know you can't set milestones.
Thanks!
I'm happy with milestones as they're currently set.
From my perspective, once 0.8.4 is out, can we merge #438 and its dependencies into the dev branch? With that I can take care of merging #449, which makes changes in a lot of places and still does the old style unit testing. #454 might need similar treatment from me, but won't be as involved.
#438
hashad merge conflictsnow, because the PRs tagged for 0.8.4, which have already been merged into master, have a different sequence than thecurrentmerge order in #438.I will need to rebaseI have rebased #438.Proposal
Declare #438 to be the first merge after 0.8.4 and have all other PRs, specifically #400, #431 rebase onto that.
We could also open a real "develop" or "0.9.x" branch even before releasing a 0.8.4 tag on master. The open PRs for 0.9 could then be based against that branch, where a reviewed #438 is merged first and the other PRs are merged after review too. No need to block future development until 0.8.4 is released.
29 remaining items
Quick updates:
- Travis CI is now turned off (removed the webhook)
- Resolution or issues for some of the items pointed out by @sawyerbfuller are in place:
- signal names in in TF and SS systems: use
LinearIOSystemclass (see above) - dlqr, dlqe: issue Discrete Time LQR Option #359 is now tagged as 0.9.x
- fill in missing elements in @roryyorke’s table in numpy.ndarray * control.TransferFunction gives array object #459: created a new issue (Implement missing type conversions for block diagram algebra #513) to track and assigned to milestone 0.9.x
- signal names in in TF and SS systems: use
It would be good to get issues set up to track the other suggestions above so that we don't lose track of them.
one more possible breaking change idea: sys.inputs and sys.outputs are different things in ss and iosys: numbers-of vs names-of, respectively. i think most would agree iosys convention, using ninputs/noutputs, is proabably a better attribute name. this is baked into a lot of places in the library though, and in user code, but easy enough to do a search and replace.
may not be worth the friction to make a change to iosys convention everywhere, but since we are talking abiut it, i thoight i would bring it up for discussion. What do you think? worth the trouble?
I agree that having the names be different is confusing and I like
ninputs,noutputs, andnstatesover theLTIequivalents. It could break people's code and so if we are going to change it, this might be a good time to do so.Sorry I have been busy with other things and didn't keep up with the squeeze discussions. Just a quick idea regarding
inputs. I also like the idea to switch over to.ninputsand co. We can replace it in our own code pretty quick and could introduce deprecation warnings for legacy.inputusage by making them class properties with getter and setter functions. Until we replace them to contain signal names in a future version.Reacted by Sawyer FullerOK, looks like everything in the discussion above that matters for 0.9.0 are addressed except for whether we want to include complex state space matrices or not (#484). It looks like that one is going to take considerable effort, so maybe we close out issue, merge pending requests #514 and #515 (after review and updates), tag 0.9.0 (but perhaps not release it, so that it is still "internal"?), and then start working on 0.9.1.
Thoughts?
I dont know what the use case is for complex state space matrices is, so no biggie for me if that gets pushed off while more substantial revisions are done/contemplated ot make that possible.
I have been hoping to that the library will be functional enough to be offered as an option for students in a digital (discrete-time) control class (UW AEM581) I am offering in the spring quarter. The good news is that in the current dev branch, things are now mostly functional for that purpose!
Having a 0.9.x public release some time this quarter would be nice so that install instructions are simple and "future-proof". But no biggie, it would be easy enough to have them download the dev branch.
Look like instruction begins 29 Mar 2021, right? If so, we can definitely make 0.9.0 (or later) available by then.
Reacted by Sawyer Fuller and Ben GreinerI put some release notes for 0.9.0 on the release notes page on the wiki. As soon as we merge #549 and possibly #546, we can release 0.9.0.
Reacted by Ben Greiner- Sounds great. S
All changes are in. Release notes are updated. I'll start the (somewhat slow) process of release 0.9.0 tomorrow (20 Mar) and then close out this issue when done.
Excellent
python-control 0.9.0 now released.
Reacted by Ben Greiner
I'm opening this issue to create a place to talk through how we are going to merge the many PRs that have built up over the past month (which is great!) in an order that makes sense (which might be hard).
As a starter, it would be good to tag PRs as something that can go in release 0.8.4 (patch level change => no existing code should stop running) versus 0.9.0 (minor version change => some code might need to be adjusted to work with the release).
I'll update this post later to try to include a list of the existing PRs, any dependencies, and which of these two releases they should go with.