many breaking changes

[CannonRS]

Hello,

at first I would like to say thank you for so much work with pymodbus. There is nearly no month with a new version.

But all the updates giv us some problems, because there are many changes, that need to fix the code using pymodbus. I'm using it for SmartHomeNG. And some plugins are using pymodbus. So we need to fix all plugins for a new pymodbus version. And there are some different version dependicies with the huawei-solar-lib (https://github.com/wlcrs/huawei-solar-lib ) too.

At the moment we talking about an replacement for pymodbus, because it's nearly impossible to let the plugins and the huawei-solar-lib work with the same pymodbus version. And the second problem is that some of the plugins are not in maintenance, so that we fix them, but does not check if it really works. No user is using all plugins.

Is there any possibilty in the future to make rarer use of breaking changes, especially the main functions?

[henfri]

I second that.
I think it should be possible to keep the API Version backwards compatible for versions of y-1 or -2 in
X.Y.Z

As one example:
slave=, slaves= replaced by device_id=, device_ids=

That is avoidable/can be Made backwards compatible easily

[janiversen]

I am not sure how you define "many breaking changes".

Over the last 3 years, we have had 8 releases with breaking changes 3.1 to 3.8, the main reason being a refactoring of the whole code to make it work better with python 3 asyncio as well as being faster and more stable.

We do have non breaking releases every 1-2 months, which are plugin compatible.

Just making changes in X versions of X.Y.Z would not allow us to make breaking changes in 2 levels. Breaking changes in Y are simple edits and often do not affect the app because it does not use that part.

The upcoming 4.0 will need refactoring a lot of apps so 3.X will be supported for a couple of years, giving apps time to upgrade.

It is of course your decision to replace pymodbus, but please do not forget to check how actively your choice is being maintained.

The majority of changes are actually backwards compatible and goes into the Z releases.

But most of the breaking changes cannot be made backwards compatible, typically because a parameter is removed, leaving the parameter without the corresponding implementation does not make sense.

The change of slave to device_id took place over several versions. First device_id was added in parallel to slave in a Z release and much later slave was removed. The last changes from slave is still not released, because they need more than a simple edit, which means v4.0.

The same is currently happening with payload, the new to/from register have been available for a year in parallel with payload. In v4.0 payload will be removed.

If you want more backwards compatibility, then feel free to start contributing, I do not have bandwidth to ensure better backwards compatibility.

If you do not want changes then freeze the pymodbus version.

[Lucas-Morais-Freire]

I seriously do now know why you removed validate() from datastores. Now when using a simulator together with a server, my client can pretty much read any address even if its marked with invalid. Also there is no handling for when you try to access an address that is higher than the maximum. it should return an exception code 2 but it goes to an except block that just returns code 4 which makes no sense.

[janiversen]

Well I seriously do not know why you seems to think it was done without reason.

validate() is merged into get/set values and is part of a bigger remake of datastores. And e.g. address address range check have been done for a longer time in the pdu.

You do no tell which version you are using but I assume it's v3.9.0 or v3.9.1

If the simulator do not work then feel free to open an issue, with the relevant documentation and it will be looked....and please do not forget being polite goes a long way in getting help.

[Lucas-Morais-Freire]

Sorry if it came across rude, I was just confused with the changes. I will prepare an issue with code for you to try to reproduce.

[henfri]

@janiversen
Thanks for taking the time to explain.
We do not want to replace pymodbus and we are grateful for the efforts you put into it. The high amount of energy you put into it, makes it difficult -despite your efforts- to keep track. Not every OSS has such an active development

Freezing the pymodbus version is also difficult, as differen plugins already are compatible with different versions of pymodbus. Even if the version could still be fixed, it would mean that we'd use artificially old versions in new plugins, leading to more effort to update those plugins later.

But most of the breaking changes cannot be made backwards compatible, typically because a parameter is removed, leaving the parameter without the corresponding implementation does not make sense.
I do understand that. But especially if the parameter is provided by name and not by order, it is not harmful to still accept it (with a warning message).

Anyway, I see that you are aware and trying to minimize our issues. That's greatly appreciated.

[janiversen]

Leaving the parameter in without functionality is a posibility, but historically that have caused issues to be raised.

And yes we try to minimize demands on the apps. Please do not forget you can have e.g. one plugin using v3.8.1 another v3.8.2 etc
without problems (if they use manifest they should > in the version check)...the only thing you cannot have is one plugin with 3.8.x and another with 3.9.x, but that should be easy for you to handle.

v3.9.x is the last of the v3 line, that should make life even easier for you, also because it will be supported for 1-2 years after v4.0.0 is released (which will be at the earliest late this year).