I am currently working on a plugin that supports various VCSes. Unfortunately, for SVN the AbstractVcs abstraction is not expressive enough for my needs; I have to use underlying SvnVcs instead. This is not in itself a problem.
But with the 2019.1 release of the Subversion plug-in, some of its API has changed (for the better, IMHO). The method signature of StatusClient.doStatus is one such example. On the surface, this means that my entire plug-in will only be compatible with 2019.1 or later.
But SVN is not the only VCS my plug-in supports and for other VCSes running on, say, a 2018.x version is fine. I am hence pondering how to change my plugin such that the SVN support is conditional on running on 2019.1+.
I could simply check (via reflection) for the signature of StatusClient.doStatus and, if it doesn't match the 2019 one, disable SVN support in my plug-in. This would mean that my plug-in runs on 2018.1 as well, just without SVN support, of course. (That is fine.)
But regardless of theidea-version/@since-build of 181, the calls to the 2019.1 API are still present in the bytecode. Thus, the intellij-plugin-verifier will complain, barring the entrance to the Plugins Repository. While I know that the probablematic doStatus call is unreachable of 2018.x, hidden after the reflective check, the intellij-plugin-verifier doesn't know that.
So what is the recommended practice to make some functionality dependent on a certain Platform version?
Splitting the plug-in in two (with different sinceVersion requirements) and linking them via an extension point would be possible, but a user with both IntelliJ 2019 and SVN installed would the need to perform two installs rather than just one to use all features of my plug-in. Is there any better way?