At the moment, the install instructions recommend installing pyrenode3 from the latest git commit, and the provided example uses the latest nightly build of Renode itself, which will change overtime even if the pyrenode3 or its examples do not.
This makes compatibility a bit confusing and hard to manage. I had Renode installed based off the latest release (1.16.1), but this was not compatible with the latest commit of pyrenode3, and there are no version tags or releases in pyrenode3 which can be lined up with Renode itself. I would prefer to use the latest stable release of Renode, but I have no clue which version of pyrenode3 corresponds to that.
I think using versioned tags or releases could help remedy this issue. We don't necessarily need to start supporting many versions of Renode, but at least we could have indicators marking compatibility.
At the moment, the install instructions recommend installing pyrenode3 from the latest git commit, and the provided example uses the latest nightly build of Renode itself, which will change overtime even if the pyrenode3 or its examples do not.
This makes compatibility a bit confusing and hard to manage. I had Renode installed based off the latest release (1.16.1), but this was not compatible with the latest commit of pyrenode3, and there are no version tags or releases in pyrenode3 which can be lined up with Renode itself. I would prefer to use the latest stable release of Renode, but I have no clue which version of pyrenode3 corresponds to that.
I think using versioned tags or releases could help remedy this issue. We don't necessarily need to start supporting many versions of Renode, but at least we could have indicators marking compatibility.