Repository navigation
Interpretation of argument for use_legacy_defaults is not clear #432
Description
My sense of the way that use_legacy_defaults should work is that if I had code that was working in some version and it stops working in a future version, I should be able to use use_legacy_defaults to return things to the version that was working.
So, for example, if I had things working in 0.8.2 and I upgrade to 0.8.4 or 0.9.0 and things stop working, I should be able to say
use_legacy_defaults('0.8.2')
and my code will work again.
This particular call definitely won't work (use_legacy_defaults only recognizes '0.8.3') and it is not clear to me how it could work. Basically, it seems like we need to track when a change in default behavior occurred and then "revert" any defaults that are different between the version I was using and the current version.
@sawyerbfuller Does my issue make sense? This is related to PR #431, I think.
Activity
sawyerbfuller commentedon Jul 18, 2020
I don’t have much familiarity with backwards-incompatible changes before 0.8.3 but I assumed that we could use this function to add such functionality as needed from feedback from users.
My take on it is that the function should be available as a “good enough” solution that allows users to avoid the thorniest issues that come up whenever there are big changes in the code (a few of which I anticipated in that PR). But not something that will include every version number and provide compatibility with minor revision of how the code works.
In short, we should be a little bit “opinionated” about how things ought to work rather than to aim to maintain perfect backwards compatibility at all times.
So, if I update to the latest version of python-control and something breaks in my code, the first thing I should try is use-legacy-defaults on various previous version numbers, one of which might fix things, but maybe not everything.
sawyerbfuller commentedon Jul 18, 2020
We could alternatively include every recent release in that function, most of which would set the same defaults as each other.
murrayrm commentedon Jul 18, 2020
I agree with the philosophy, especially the summary sentence:
But this means that
use_legacy_defaultsneeds to take an arbitrary version number and do the "right thing", which I don't think it currently does. Eg, if I were using 0.8.2 and things were working, then I got to 0.8.4 and things break, in the current implementation I would need to know to calluse_legacy_defaults('0.8.3')even though I never personally used 0.8.3.I think a bit of clever parsing of the version number and lexicographical comparison would allow an implementation where if I enter a version number I get the legacy defaults for anything that changed after that version number.