GeezerVison is showing github.com — Release 0.8.4 and 0.9.0 sequencing · Issue #451 · python-control/python-control
Release 0.8.4 and 0.9.0 sequencing #451DescriptionI'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. Activitymurrayrm commented on Aug 16, 2020 Tried adding @bnavigator to this issue, but not showing up on the list. Mentioning here instead. bnavigator commented on Aug 16, 2020 bnavigator commented on Aug 16, 2020 #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) sawyerbfuller commented on Aug 17, 2020 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? murrayrm commented on Aug 17, 2020 I can add your new account as a developer (and remove the old one). murrayrm commented on Aug 17, 2020 OK, you should now have developer privileges @sawyerbfuller. Let me know you can't set milestones. sawyerbfuller commented on Aug 17, 2020 sawyerbfuller commented on Aug 19, 2020 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. bnavigator commented on Aug 19, 2020 #438 has had merge conflicts now, because the PRs tagged for 0.8.4, which have already been merged into master, have a different sequence than the current merge order in #438. I will need to rebase I 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. murrayrm commented on Jan 18, 2021 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:
It would be good to get issues set up to track the other suggestions above so that we don't lose track of them. sawyerbfuller commented on Jan 19, 2021 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? murrayrm commented on Jan 19, 2021 I agree that having the names be different is confusing and I like ninputs, noutputs, and nstates over the LTI equivalents. It could break people's code and so if we are going to change it, this might be a good time to do so. bnavigator commented on Jan 19, 2021 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 .ninputs and co. We can replace it in our own code pretty quick and could introduce deprecation warnings for legacy .input usage by making them class properties with getter and setter functions. Until we replace them to contain signal names in a future version. murrayrm commented on Jan 20, 2021 inputs to ninputs in PR #515.
murrayrm commented on Jan 20, 2021 OK, 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? sawyerbfuller commented on Jan 22, 2021 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. murrayrm commented on Jan 23, 2021 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 Greiner murrayrm commented on Feb 25, 2021 I 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. murrayrm commented on Mar 13, 2021 Update: as soon as we merge PR #558, #566, and (optionally) #569, I think we are good to go. I'll target doing the release starting around 21 Mar. sawyerbfuller commented on Mar 14, 2021 murrayrm commented on Mar 20, 2021 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. sawyerbfuller commented on Mar 20, 2021 murrayrm commented on Mar 20, 2021 python-control 0.9.0 now released.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|