How best to handle multiple versions?

With the upcoming change of platform type dependencies (where the Community and Ultimate versions merge together), I am for the first time forced (I think) to produce two versions of my plugin. I am unsure how best to do it.

Today I use intellijPlatform.create(IntelliJPlatformType.IntellijIdeaCommunity, ...)as my plugin only depends on the base platform. I assume this must be changed to intellijPlatform.create(IntelliJPlatformType.IntellijIdea, ..) to work with 2025.3.

Should I set a untilBuild=252.* in my build.gradle in one branch, and then then sinceBuild=253 in another, and build both versions? If so, how does it work when publishing two different versions to the Marketplace? What version names should my plugin have so that it show that this is a single release, but the right version is installed depending of the version of the user’s product?

If I have missed where this is documented, I appreciate pointers.

Please note that this SDK no longer exists in 2025.3 version

Did you even read the question? It’s exactly because this SDK is removed that I pose the question.

You can split the audience using since/until build attributes, so when you upload versions for 2025.2 they are not compatible with 2025.3

Choose some versioning schema compatible with SemVer, it allows suffixes for versions.

E.g. commonly used approach I see in plugins is 1.2.3-251

With the upcoming change of platform type dependencies (where the Community and Ultimate versions merge together), I am for the first time forced (I think) to produce two versions of my plugin.

Is that assumption correct? Maybe the IntelliJPlatformType.IntellijIdea etc. are only used during plugin development. When I look at the zip file created for my plugin, the plugin.xml contained there does not have any reference to IC (that I currently declare as dependency) but only the dependencies like <depends>com.intellij.modules.platform</depends> that I wrote into the plugin.xml by hand. I.e. I would assume that no two plugin versions are required.

You might be right. The issue I have faced the last couple of weeks since the first 2025.3 EAP was published is that my builds fail because gradle verifyPlugincannot run anymore, with the error: Could not find idea:ideaIC:253.20558.43. This is of course because the dependencies will change in 2025.3. So my problem is more building the plugin rather than running it (I have not yet tried to run it in the EAP). So it might be that this is only a build problem, and I need to remove verifyPlugin from my builds. That’s a shame, but doable.

I think you targeted IC, and now you’re wondering what you should do? In a few words: you can now target IU (if targeting 2025.3 builds). Your plugin will continue to work with IntelliJ builds. Even with older IC.
Just in case, because this may not be super clear for everybody (it wasn’t for me some time ago):

  • targeting vs compatibility range:
    • when “targeting” an IDE, you simply build your plugin with the classes of the targeted IDE in the classpath. It does not affect the plugin compatibility. Actually, it has no impact on the generated plugin archive. You target an IDE to resolve IDE classes, get deprecation warnings, test your plugin in a sandboxed IDE, etc. Actually, you can target WebStorm if you want, and your plugin will stay compatible with IntelliJ.
    • the IDE compatibility depends on the IDE modules your plugin depends on. If you depend on the default modules (com.intellij.modules.platform), you will be compatible with all IntelliJ based IDEs: IntelliJ Community and Ult., WebStorm, PyCharm, Gateway, etc. You cannot directly say if your plugin should work with specific IDEs. This is calculated automatically. To limit the compatibility to a specific IDE, you must declare a strict dependency to one of its modules. Per example, if you declare a dependency to the Angular module, your plugin will be compatible with IJ Ultimate (with a paid license, because it as the Angular plugin), WebStorm, and if my memory is correct, PhpStorm.
    • the compatibility range says if your plugin is compatible with a range of IDE versions. These are the since-build and until-build fields in plugin.xml. In most case, this is the IntelliJ version, because all IntelliJ -based IDEs share the same build numbers. Per example, a 242 build number can refer to IJ 2024.2, WebStorm 2024.2 (which is based on the 2024.2 IntelliJ platform), etc. PS: Android Studio uses different version numbers, but it also indicates the IntelliJ Platform build numbers.

So, with the new unified builds, IC is gone and you will target IU. BTW, if your plugin is compatible with older IDEs, you can continue to target older IC. Target IU 2025.3 only if you want to test your plugin in a IU 2025.3 sandboxed IDE, get compatibility hints in the IDE, things like that. While targeting IU 2025.3, this won’t affect compatibility with older and other IDEs.

Finally, I think that (the new, unified) IU should have been renamed IJ. That would have been less confusing :wink:

2 Likes

Thank you for the reply. It seems clear that I will not have to build multiple versions.

However, there is still the specific problem with the gradle verifyPlugin task: If I build my plugin right now without an untilBuild-property and with the target IntellijIdeaCommunity, the verifyPlugin task will fail since it will try to download the community-edition of 2025.3, which does not exist. I thus have to either set untilBuld to 252.*, or disable running verifyPlugin in my build scripts.

1 Like

Yes, if the plugin verifier doesn’t work with its recommended settings, you may need to adapt your configuration. And open an issue, if needed.