Do you know how they end up in EAP users then? We do not suggest EAP to regular users in product, you can only go search for it
I donāt. I imagine theyāre the type of folks who go into settings and tinker around with things they donāt understand, but since itās not a problem Iāve had to address in quite a few years, I havenāt had the opportunity to ask those users why they enabled EAP builds. I just know that it happened, and it happened more frequently than Iād have expected, and the affected users would just start spamming me with bug reports about my plugin not working with the unreleased product that they suddenly had installed. And thatās an avoidable waste of time for both my users and myself, so I avoid it.
You donāt have to agree with this, but itād be really nice if you at least accepted that some of us are speaking from a perspective of hard-earned experience and have made business-level decisions accordingly.
There are also no ways to enroll from the stable IDE, really. You need to look for it, or you are trying to find a way to not pay for IDE, this way we certainly know
If memory serves, when I made the changes to constrain to released/tested versions, Settings | Appearance & Behavior | System Settings | Updates had the option to include EAP/pre-release builds, so it was easily accessible. I honestly didnāt even know that that had been removed at some point. But it is still available through Toolbox, no? And I know that a number of my users install/manage their IDEs through Toolbox.
Cannot find any leads, and even in Toolbox it requires going deeper.
Do you consider this ādeeperā?
Because thatās right under Tool actions | Settings for the installed IDE.
I donāt know what addiitonal value there is to this discussion. Youāre not going to convince me to put my usersā primary tool stability at risk. Iām obviously not going to convince you that thereās an actual problem if I were to do so.
I would just ask that you have a bit more respect and consideration for those who have staked their businesses on JetBrainsā platform ā some of us for quite a long stretch ā and trust that weāve made informed decisions for those businesses and the associated end users.
I am not going to convince, but I need to share arguments and the relevant state so it is balanced discussion.
In the end I see that you decided to not manage expectations of users but instead limit testing capabilities for them, your choice and it even may be worse for the quality of your plugin, longer feedback loop
In a long run, we will stimulate vendors and promote work of people who help us and our EAP program. So not only the words we have
I would argue that removing our ability to constrain until-build which, as Iāve commented previously, only means my users have to wait a day or two before upgrading, achieves the same.
But I agree with Scott, itās clearly futile to argue this. Iāll just reiterate my displeasure with this change and how itās been handled, and get on with my day.
Okay, this statement is of concern to me. Unless Iām misreading it, it sounds like youāre saying that if a plugin developer chooses to limit participation of a plugin in JetBrainsā EAP program, that plugin will be reduced in the JetBrains Marketplace ecosystem from a support/visibility/promotion standpoint.
I canāt tell if this is the official stance or just yours.
I think Iāll follow up with my Marketplace contacts to get a better understanding of this stance/statement as my current EAP strategy was based on guidance from JetBrains at the time that I was seeing significant issues with users upgrading to early EAP builds.
1 Like
But no, I say we power up people who make their plugins more accessible and compatible via a positive stimulus. And then better products can win from following.
Please tell me if Iām wrong, but something similar to the NetCAT program, and/or the possibility for plugin developers to play with the first EAP builds a few days before the regular users, would mitigate these issues?
Iām saying that because it actually worked for NetBeans. This was a good thing.
We are investigating a possibility to have Nightly channel on IDEs available for selected groups of people. Could it help?
1 Like
If it can help plugin developers to be ready when (per example) the first EAP build of IJ 2025.4 or 2026.1 is out, I think this would be a good step in the right direction 
I donāt know how these nightly builds work. Are they stable enough for testing? If we test our plugin with nightly builds, how confident should we be when the first EAP version arrives? I think this is the main problem here. Plugin developers and users discover EAP builds at the same time.
Also, is it so important for regular users to have such quick access to EAP versions?
1 Like
This right here is at the heart of the issue. Thanks, @jonathanlermitage.1, for putting it so simply!
JetBrains releases an EAP build overnight for some of us, and, when I had an open-ended until-build, by the time I would get up in the morning, my users would have already started reporting issues against that build that I had absolutely no way of finding/fixing. Then I was automatically in a reactive/triage mode, and without limiting until-build, I had to keep dealing with issues that are not things I can fix myself, the DoNotAskAgain issue I reported yesterday being a key example.
If there were even perhaps a plugin dev-oriented āpre-EAPā build that we had access to a very short time before the more broadly-available EAP ā and if JetBrains would make a best effort to address any genuine breaking plugin SDK changes during that phase and before the EAPā¦along with plugin devs making a best effort to addressing any changes that affect their plugin but have a workable migration path ā that would likely help to mitigate the issues that we plugin devs have been describing here.
1 Like
There is a further problem with this change, apart from the issue with EAP versions.
To avoid breakage due to inevitable API churn across versions, Iāve been using until-build to mark which platform versions my plugin is compatible with. I use a versioning scheme of <my version>-<platform version>, so 2025.2-251 is the 2025.2 version of my plugin, built for the 2025.1 version of the platform (`until-build` of 251.*). That way, I can ensure that that version of the plugin works with that version of the platform. This has worked well, because the IDE installs the latest version which is compatible with the declared build range, and because of the way the versioning works, they would get the latest version of my plugin for the version of the platform that they are using.
Users frequently donāt upgrade IntelliJ for all sorts of reasons. Maybe theyāre on a fallback licence, maybe they just donāt find the new features compelling and would rather not risk breaking their work tools, maybe they just canāt be bothered learning where things are in a new UI layout they didnāt ask for. Many of my users are only using IntelliJ because of my plugin, so if they canāt get their company to pay for an upgrade to my plugin, they want to stay on an older IntelliJ so they can keep using the most recent version of my plugin they have available.
With this change, thereās now no way I can prevent their IDEs from installing versions which wonāt work with their platform version. Their IDE will install the most recent version, and since the until-build is ignored, theyāll get the most recent version of my plugin for the most recent IntelliJ platform, which is almost guaranteed to give them problems. My understanding is that we can get around this by manually setting the until-build version in the marketplace, by hand, for every version, on every deploy, but this is a ridiculously onerous way to handle this. Weāve been promised details on this is supposed to work āvery soon nowā since February, and now the change is here but we still have no details of how this will work. So, how are we supposed to support this use case?
And we had better take more time before rolling out in release to check everything, hope it is much better than quick dramatic updates.
1 Like