Repository navigation
Release 0.8.4 and 0.9.0 sequencing #451
Description
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.
Activity
murrayrm commentedon Aug 16, 2020
Tried adding @bnavigator to this issue, but not showing up on the list. Mentioning here instead.
bnavigator commentedon Aug 16, 2020
@sawyerbfuller goes by a different handle now?
bnavigator commentedon 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 commentedon 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 commentedon Aug 17, 2020
I can add your new account as a developer (and remove the old one).
murrayrm commentedon Aug 17, 2020
OK, you should now have developer privileges @sawyerbfuller. Let me know you can't set milestones.
sawyerbfuller commentedon Aug 17, 2020
Thanks!
sawyerbfuller commentedon 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 commentedon Aug 19, 2020
#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
murrayrm commentedon Jan 18, 2021
Quick updates:
LinearIOSystemclass (see above)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 commentedon 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 commentedon Jan 19, 2021
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.bnavigator commentedon 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.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.murrayrm commentedon Jan 20, 2021
inputstoninputsin PR #515.murrayrm commentedon 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 commentedon 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 commentedon 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.
murrayrm commentedon 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 commentedon 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 commentedon Mar 14, 2021
murrayrm commentedon 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 commentedon Mar 20, 2021
Excellent
murrayrm commentedon Mar 20, 2021
python-control 0.9.0 now released.