Version 0.10.2 release notes #1140
Conversation
67c1e66 to
7548738
Compare
There was a problem hiding this comment.
Excellent!
Not related to this PR but relevant in terms of the docs: pinning docutils at 0.16 is not necessary now because the current sphinx_rtd_theme release is compatible with later versions. I removed the pin from requirements.txt and locally the result looks good to me, though I did not carefully compare it side-by-side with the current case (of docutils pinned at 0.16). If you think this is too risky to do now, OK to wait and make the change after releasing version 0.10.2.
If you have access to the ReadTheDocs admin panel, it is worth checking why a warning banner is not appearing on older versions, as I commented in a recent issue.
While reviewing, I noticed a misprint in the docs: "indexed indexed" appears twice in timeresp.py:
python-control/control/timeresp.py
Line 554 in 394e1c2
python-control/control/timeresp.py
Line 619 in 394e1c2
doc/releases/0.10.2-notes.rst
Outdated
| * `FrequencyResponseData`: use `~FrequencyResponseData.complex` to | ||
| access the (squeeze processed) complex frequency response (instead | ||
| of the legacy `response` property) and | ||
| `~FrequencyResponseData.frdata` to access the 3D frequency response |
There was a problem hiding this comment.
This does not render as a link to frdata for me when I build locally. This is expected because frdata is an attribute, whereas complex is a property. Attributes defined by assignment to self do not have documentation besides the class docstring, whereas the property definitions are functions and thus can have their own docstrings.
You might already be aware of the above, but I wanted to write it out to share my understanding while reviewing this PR.
There was a problem hiding this comment.
Consider changing this to
`FrequencyResponseData.frdata <FrequencyResponseData>`
as it is written in the "Deprecations" section below.
There was a problem hiding this comment.
I've made the proposed change, but for future we might consider documenting attributes. This can be done by defining the attribute in the class and using the #: syntax in Sphinx. So something like this:
class FrequencyReponseData():
...
#: Frequency response data array.
#:
#: The frequency response at each frequency point. If 1D, ...
frdata = None
I looked into this and the settings are such that we should see warning banners. But we don't. I've added @slivingston as a maintainer in case you have time to look and want to debug. |
Thanks. It turns out that ReadTheDocs follows the Semantic Version specification, which states that versions less than 1.0.0 are for "initial development" and not stable. ReadTheDocs allows us to manually declare which version is stable by pushing a branch named |
|
Thanks for the ReadTheDocs fix, @slivingston. What do we need to do when we make a new release? Copy that release into stable? |
Yes. Basically, the branch should point to the same commit as the tag used for the release: |
This PR contains release notes for version 0.10.2 of the python-control toolbox. This should be the last PR merged before release v0.10.2 (with addition commits if any new functionality is added via other PRs).