Providing backward compatibility

Answered

Hello!

I have a plugin where currently the minimum supported IntelliJ Platform version is 221 and maximum is 221.*.

In my plugin, I have a class that implements the `VcsLogHighlighter` interface and therefore overrides and implements the method `getStyle` from the interface. I noticed that the method signature for `getStyle` will change with platform version 222. If I would like my plugin to have backward compatibility with platform version 221, while also having compatibility with the upcoming platform version 222, what would be the best way to achieve this?

I understand I can just modify the method signature on my side to comply with the new method signature in 222 but then my plugin would no longer be backwards compatible with 221.

Thanks!

2 comments
Comment actions Permalink

If you need to support both versions, the cleanest solution is to maintain two separate branches in your plugin, each targeting distinct IDE version(s) with according set since/until-build setup.

0
Comment actions Permalink

The way I maintain compatibility in my project is to have an intellij-compat JAR that has compatibility APIs for each supported version. "[VERSION]/compat" provides support for the older version without the new/modified API and "[VERSION]/native" provides support for the newer version. I then add the relevant paths to the source directories based on the IntelliJ version.

Getting the IntelliJ version: https://github.com/rhdunn/xquery-intellij-plugin/blob/master/build.gradle#L5-L36. I use the patchPluginXml.sinceBuild property (line 191-193) to set the IntelliJ version in the plugin.xml file to that targetted IntelliJ version.

Compatibility JAR (see biuld.gradle for the logic to add the paths): https://github.com/rhdunn/xquery-intellij-plugin/tree/master/src/intellij-compat

I use various techniques to implement the compatibility code taking advantage of several Kotlin features. For your case, I would try something like:

1. Use a typealias to import the native interface. If using Java, you can extend the interface.

2. For the compatibility version, define the new version of getStyle and a default implementation of the old getStyle that calls the new version.

If you can't easily override getStyle (e.g. if the new version cannot be used along side the new version), you can define a getStyleEx function in both the native and compatibility versions, and provide a default implementation of each getStyle that calls the new getStyleEx method.

2

Please sign in to leave a comment.