Ability to specify minimum dependency versions for backwards compatibility

[morph166955]

Not sure if this goes in core, addons, or distribution. My apologies if this goes somewhere morr appropriate.

With 4.0.0M1 dropped on Friday we have seen a good uptick in numbers of users who have moved to 4.0.0. With that has come a number of threads asking about jar compatibility with the marketplace. The vast majority of what I've seen can be fixed by creating jars with a few flags sent to maven to specify lower java and karaf versions as (in most cases) the developers haven't implemented anything that require the newer versions.

To prevent issues in the future, it would be nice if the developers could specify the minimum dependency versions in the specific binding so that they become more backwards compatible. For example, on the AndroidTV binding I'm not doing anything that specifically requires Java 17. If I could put something in the xml that says "requires minimum java 11" rather than defaulting to 17, the jars wouldn't break as people upgrade. If the developer eventually does use a feature in a higher version they can then dial up their specific xml as needed. Alternatively, put a flag in to say "minimum OH version". So for example, specify that the jar should work in all versions from 3.4.0 and up. I realize things like the migration from bindings.xml to addons.xml complicates this, but it would be a step forward into preventing issues as people migrate in the future.

[J-N-K]

I don't think this is possible. There are other incompatibilities besides the Java version, e.g. the karaf version.

[morph166955]

I was using java as an example, but yes there are definitely others. For the marketplace I generate my jars by specifying "-Dohc.version=3.2.0 -Dmaven.compiler.source=11 -Dmaven.compiler.target=11 -Dkaraf.version=4.3.7". As I'm not doing anything specific to the newer versions this generates a jar that works on all of the versions from 3.2.0 and up. If I could specify this in (example) the pom.xml on the binding, then as core upgrades happen the marketplace stays stable and backwards compatible.

[J-N-K]

That jar works on OH4?

[morph166955]

Yup. The only thing I have to do is readd the binding.xml file (so both are there). Been doing it for a while now.

https://community.openhab.org/t/androidtv-binding-3-2-0-4-0-0/142203

[morph166955]

Thinking about this a little more, to avoid old dependencies from causing issues (e.g. we probably don't want someone specifying 2.5 or 3.0 at this point) perhaps a policy of 2 version bumps maximum? So for example here, set a minimum of OH 3.3.0 for 4.0.0, then 3.4.0 when we go to 4.1.0, etc. It gives the developers time to update their addons without holding back the changes in the core.

Similarly, while I understand the move to addon.xml, it may be better to have both binding and addon for some period of time and then sunset it later to retain the compatibility. Since the core upgrade stopped looking at binding, it wouldn't really hurt anything to have it there.

Again, just looking to figure out how to minimize impact to the community, specifically the marketplace, when breaking changes happen in core updates.

[morph166955]

As a test, I threw this into the AndroidTV binding. I preface this with, I realize this isn't a good idea to do across every addon, I'm not suggesting that we do this on all the addons, this is a test. That said, it worked.

https://github.com/openhab/openhab-addons/pull/14282/commits/0811ce02b09453d9dcd53f575463f8299819f6f5

It seems to compile just fine and the jars seem to be compatible across versions. This works for me since I'm not doing anything beyond java 11 or karaf 4.3.7. There are probably a few other things to update, perhaps requireJavaVersion.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/binding-compatibilty/145185/11