TODO: Improve breaking upgrade repair issue

[raman325]

Today we create a repair issue when we detect an incorrect server version: https://github.com/home-assistant/core/blob/dev/homeassistant/components/zwave_js/__init__.py#L161-L169

We should improve the mechanism to point users down the right path when we can

[kpine]

You might also consider relaxing the minimum schema supported when possible. Does supporting a new schema version always require abandoning support for a previous version?

[MartinHjelmare]

If we don't bump minimum version in the client we would need to maintain compatibility code both in the server and in the client. Today we only do it in the server.

[raman325]

The main reason why we require breaking changes is when new properties are added or new commands are added in the server that we want to add support for in the integration. If we wanted to, there are two options that would eliminate the breaking changes, neither of which I like, but for full transparency:

1. Rely on the require_schema parameter in each model method in the lib. The end result would be that, if no other changes in HA were made, some functions would throw an error because the require_schema would be too high.
2. Add code to HA that selectively adds functionality based on the schema version of the server.

In my opinion, 1 results in a poor user experience and 2 adds unnecessary complexity. But they would allow us to stop bumping the min version as often as we could be selective about when we applied these strategies and when we decided a minor version bump was needed