I always try to release a new version of my plugins as close as possible to the first EAP, but I believe removing the until field is a bad decision.
If I don’t make it in time for the EAP, those brave developers who upgrade early will face breaking compatibility issues unless I go through all my previous releases on the Marketplace and manually add until build constraints until I can fix them. With four plugins and a full-time job, this isn’t something I can do quickly.
Since I personally use the latest EAP builds myself, I know firsthand how frustrating it can be when plugins break. I’ll have to think twice before updating because I’ll run into issues from all plugins that haven’t been updated yet.
The more advance notice we have about upcoming releases, the easier it is for us to prepare. Still, I really hope you’ll reconsider removing the until field.
honestly, I don’t understand what JetBrains gains from removing the until field. Maybe you could run an automated check across all (or a set ) Marketplace plugins and automatically set the until value for those that are not compatible with the latest version. That way, users won’t encounter breaking errors just because a plugin wasn’t updated in time. It would help maintain a smoother experience for both users and developers.
The issue I was concerned about in the previous message has just occurred:
A user opened a ticket after upgrading to EAP 253, reporting an exception when using my free plugin that was only compatible with 252-*.
This raises an important question: Are plugin developers expected to release updates immediately when an EAP version is published? We don’t even receive advance notice about EAP releases—we only learn about them after they happen.
Please advise what we should do now with all the versions of all our plugins that doesn’t have an until value.
Thank you @yuriy.artamonov for your response, but I’m concerned that your “biggest wish” may conflict with both user experience and plugin developers’ workflow.
The new approach could lead to several issues:
Users uninstalling plugins that suddenly become incompatible
Negative reviews for plugin developers
Plugin authors being forced to update all their plugins with extremely tight turnaround times
I don’t see how this benefits anyone, even your early adopters will have a negative experience. If you want to ensure plugin availability for EAP users, I believe better collaboration and communication with plugin authors would be more effective than this approach.
What should I do now? I got four plugins X ten+ versions each with 252+, I need to go on the web and set the until manually?
So on the one hand, you want the plugin to be available in the EAP (this is your wish right?) and from other you don’t care if the plugin is not working?
Sorry probably that is just me but I really don’t get why.
We care to receive issue reports on this and we promise improvements in compatibility. Because we need diverse feedback on EAP, including usage of plugins.
Otherwise bugs will be revealed too late, it hurts regular users
In the past (when NetBeans was owned by Sun, then Oracle), I participated to the NetCAT program several times. This is was community of volunteers (selected by Sun/Oracle) involved in testing release candidate builds of NetBeans. This was a great experience.
I know EAP builds of IntelliJ are public, but I think you could create something similar to NetCAT just for the very first EAP builds of new major IJ versions. Per example, the first EAP build(s) of IJ 2025.3 could be private to the JetBrains staff + a community a plugin developers. This would help plugin developers to fix issues before the first public EAP builds. Or, when a new EAP is built, make it private to this community just for a week.
I suggest that because I was a NeCAT member/leader, and a member of the official team of plugin verifiers for NetBeans. I miss those days.
I know JetBrains IDEs and NetBeans are very different. Paid/private business vs free/opensource, but I sincerely believe that JetBrains would benefit from being a little bit more open.
This is a wide subject. From my point of view, plugin developers are tolerated on the marketplace, but there are no discussions. At least, these are mostly one-way discussions: announces for breaking changes, new rules on the marketplace… This is frustrating.
I’ll weigh in here as well. As I stated previously in this thread, I constrain until-build for my plugin to the last released version until the EAP reaches a release candidate state.
The breaking plugin SDK change that I filed just yesterday in 2025.3 EAP is a perfect example of why I do this. If I remove until-build and my more adventurous users upgrade – and some always do if unconstrained – there is a very high likelihood that at least some features of my plugin will break until such incompatible plugin SDK changes are addressed.
And to be clear, it’s not always due to breaking plugin SDK changes, but sometimes I will not yet have updated my plugin to migrate from a previously-deprecated-now-removed API to a replacing API that is available across supported versions. I may not see the need to do so until I actually try to build my plugin against the early EAP builds’ newer SDK and see compilation failures, spurring me to find and use the replacing APIs.
But unfortunately it’s not at all uncommon for there to be an (understandably unintentional) break in backward-compatibility just as I reported yesterday, and, if not avoided by constraining the supported version range, that can result in otherwise unnecessary support overhead and frustration from end users of my paid plugin.
Since there’s really no reasonable way to guarantee that early-phase EAP builds will be 100% backward-compatible with at least the last released IDE version, I must retain this stance of restricting the supported range to supported, tested IDE versions to minimize disruption to my customers. And as I said, once the EAP builds reach an RC state, I do unlock compatibility with a customer-facing caveat that there could still be breaking changes between those builds and the final GA builds.
Cannot agree here, they enroll into our EAP program and they understand what they are doing. They explicitly accept the fact that they use test versions and they are not stable.
With such a stance, you basically hurt the EAP program and limit feedback and issues that we could recieve
All I can say is that when I did not explicitly constrain until-build to include only supported, tested IDE versions, I would wake up the morning after JetBrains would release an EAP to find that a non-trivial number of my plugin’s users had updated and were encountering issues. I would have to guide those users on how to roll back to the last released version. Once I started constraining until-build as I do now, that ceased to be an issue. It’s the right decision for my product and its customers. Period.
No, they’re not, at least not in the same manner you’re implying.
Unlike the vast majority of users of the core JetBrains products, many of the users of my product are not as deeply technical. Many of them come from a more business-oriented background and find themselves in a technical role organically and by necessity. They see an upgrade notification – even one for which they had to explicitly opt-in – and assume that by accepting it, they don’t risk a loss in productivity with their day-in-day-out primary tool. Yes, it’s a flawed assumption, but it’s one that actually happens in the real world. I saw it happen repeatedly.
And I will never say to my valued paying customer, “But you asked for it!” Instead I will help them out of the situation in which they’ve put themselves, or in this case, I will do what I can to help prevent them from ever getting into that situation to begin with.