Add IC-LATEST-STABLE and IU-LATEST-STABLE values for intellij.version property

[jonathanlermitage]

Describe the need of your request

Like IC-LATEST-EAP-SNAPSHOT, it would be nice to have a flag like IC-LATEST-STABLE (and IU-LATEST-STABLE) in order to use the latest stable IJ release (today, it would be "IC-2023.3.4").

Proposed solution

Be able to declare something like this in build.gradle.kts:

intellij {
    version.set("IC-LATEST-STABLE")
}

Alternatives you've considered

For now, I implemented this in my gradle build: https://github.com/jonathanlermitage/intellij-extra-toolwindow-colorful-icons/blob/main/build.gradle.kts#L231-L258
But I think this feature could be integrated into the gradle-intellij-plugin project.

Additional context

I used to test my plugins with 3 versions:

• minimal IDE version (hard-coded, as it depends on my own plugin)
• latest stable version (idealy, something like IC-LATEST-STABLE). I am also using this version when developing in my IDE
• latest EAP snapshot (IC-LATEST-EAP-SNAPSHOT)

[YannCebron]

I don't think that "build your plugin against whatever is $LATEST$ at this point in time" is a common usecase.
Especially, given easily introduced incompatibilities.

[jonathanlermitage]

I'm not sure to understand. LATEST-EAP-SNAPSHOT is even less stable.
Just to explain how I work: I do my best to test my plugins with a minimal IDE version, and a maximum IDE version, which is the latest stable build. EAP builds can break (these are EAP, after all), I will check that later.
Also, because I maintain some (8) plugins, I don't want to update my projects every time a new stable IDE build is available. This is so boring. A value like LATEST-STABLE is useful.

Some plugin developers asked on Slack how to get the latest stable build number. I believe it would help some of us. I don't know if this is a very common use case, but it exists, and it seems valid.

[YannCebron]

EAPs are provided for these two reasons:

a) check compatibility of existing plugins
b) explore/start using new API before GA

There is no need to build your plugins against the latest GA, unless you explicitly need its features/bugfxes in your plugin.

[jonathanlermitage]

Yeah, I need to test my plugins with the latest GA. Users report some issues, and the fix is on the IDE side. I wait for the next GA (or the next GA that comes with the fix), check everything works, then I let users know they should upgrade their IDE.

I am also building against latest GA for these reasons:

• I want to be informed about the latest available API, their changes and deprecated APIs, via my IDE; without using an EAP build
• there are (at least) two ways to configure the plugin compatibility version range in plugix.xml: by setting the since-build and until-build attributes, and by setting the since-build attribute only. I prefer the second option, because:
  • I don't want to publish a new version just for upgrading the until-build attribute (many users say upgrading their plugin(s) is annoying because of that. A good example is the official "ini" plugin). So, I make my plugin compatible with a minimal version, and I want to build and test with the latest GA in order to be sure there's no issue. My plugins should be stable with stable IDEs. They can install plugins on EAP, at their own risk.
  • the latest GA may introduce some new bugs, or some APIs may have different (and not documented) behavior, which may impact my plugins. I want to check that, but not with latest EAP.

This is why I am using something like a LATEST-STABLE thing, daily. It may be uncommon, but do we have statistics? I have no idea 😅