Prefered way to handle detected structural changes in a device?

I’m implementing a binding which, at least initially supports 3 different models, which currently have three different firmware versions… so 3 to the third permutations. The binding can identify the model and firmware version in order to know which definitions to use in order to determine how to configure the channels and their statuses.

However, if someone has already setup their device, say model x with firmware v1, then they download and install firmware v2, binding will notice the change so there are some decisions to be made.

First, there may or may not be a definition available for the version that got installed. I just upgraded my firmware last week and I have to new definition in testing now, but in the future users will have access to the latest firmware before a definition becomes available. In that event, the binding needs to decide if it should keep working, not knowing what the result will be, or refuse to go online until it can find a definition for the installed version. (Unfortunately, you can’t read the definition from the device, it needs to be distilled from the manufacturers documentation)

The other possibility is the user was on an older firmware and finally upgraded to one for which a definition already exists. In that case the binding could drop and recreate the channel definitions, but that will certainly have an impact on the Items and such so they may have some work to do.

Basically I’m wondering what the preferred methodology is that would bring the least pain.

I’d define 3 Thing types and handle the different firmware features within the Things.

You can remove Channels dynamically that are not supported by the current firmware version.

When the manufacturer adds a new feature, but doesn’t break the API, I’d expect the Thing to continue to work (without the new feature, until you implement it).

When the manufacturer breaks the API, your binding will hopefully notice that and set the Thing status to OFFLINE with an appropriate (technical) error message.