Repository navigation
Releasing 0.9.4 and moving to 0.10.0 #904
Description
I am planning to do a new release (0.9.4) in the coming days that will include all recent PRs except #881, since that may have some incompatibilities due to the requirement to use lists (versus tuples) in some parts of the interconnect interface.
Are there any additional changes we want for 0.9.4?
For version 0.10.0, I was thinking that we might:
- Add in the new multivariable interconnect functionality
- Get rid of support for the NumPy
matrixclass (no longer recommended by NumPy, though not yet deprecated) - Consider other changes that would require small rewrites of working user code.
Use this issue to post thoughts and suggestions.
Activity
sawyerbfuller commentedon Jun 5, 2023
I think I have everything that I hoped to for a .9.4 release already submitted.
As for .10, I am in favor of using that release to begin phasing out deprecations, most notably the matrix class.
Another possible future change to consider for that time frame is merging
StateSpaceandLinearIOSystemclasses. Are there any reasons to keep them separate aside from the effort to refactor the code? There is also the matter of what the resulting class should be called.What's needed for a 1.0 release? Here are two possible features that come to mind that may be worth considering:
sawyerbfuller commentedon Jun 5, 2023
As long as we are talking about architecture, I had a question about the use of the dictionaries
input_indexandoutput_index. Is there any chance we could get away with a simplification in which signal names were stored entirely ininput_labelsandoutput_labels, which are lists of signal names? The location in the list could encode the index of the signal. To find the index associated with a name/label, you would use the syntaxsys.input_labels.index('u')rather thansys.input_index['u']-- a few more characters, but fewer fields to keep around and keep in sync. But I really don't know all the ways these are used -- especially as we move toward multivariable interconnect -- so I may be missing something.murrayrm commentedon Jun 5, 2023
There are not actually two separate class variables. Instead
input_labels(and the others) is a property that just returnsinput_labels.keys(). So no syncing issues (and you can usesys.input_labels.index('u')if you like -:).murrayrm commentedon Jun 6, 2023
Regarding system classes, here is what we have now:
I think we can do the following:
This would give us something like this (focusing just on the I/O system classes and leaving out FRD):
sawyerbfuller commentedon Jun 7, 2023
That makes sense! - I agree with your suggestions for how to collapse the class hierarchy.
Also - sounds good in regards to putting off multivar interconnect to the next release. Might be nice to have some time to experiment with it once it is merged because of the aforementioned changes.
bnavigator commentedon Jun 7, 2023
Hi, I am sorry that I can not participate much in the discussions recently. I am in preparation of my upcoming PhD defense.
As far as I can tell, all suggestions look good to me, though.
murrayrm commentedon Jun 19, 2023
Closing this issue since 0.9.4 has now been released. Discussion on 0.10 is moved to #917.