When are the first releases of the 2025.2 major version going to land?
That would help to schedule my most work to be ready 
Thanks!
1 Like
It will be ready when it is ready
I asked the same question with a previous version and got a similar answer of “Soon…”
I think it is a fair question that deserves a good answer or “We don’t know yet..” but that is just my opinion…
You can take a look at the previous years, we are +/- consistent with weeks when releases happen.
According to jetbrains-ide-release-dates/ides/IntelliJ_IDEA_Ultimate_Release_Dates.md at main · ChrisCarini/jetbrains-ide-release-dates · GitHub, IJ 2025.2 should be released within 2~3 weeks.
I came here to share this 
- I’m flattered it was already shared by someone else 
All technical concerns aside, I expect the decisions around introducing a new default UI theme to play a large role in dictating when the release is “ready.”
We have no plans to release the new theme just yet as final so no
1 Like
Now that it’s in RC, are you able to offer any more specific date or date range?
I generally try to release a tested build of my plugin that updates until-build for the new version once RC is available so that, when GA builds are released – typically overnight for me – I don’t suddenly find the inevitable set of users who upgrade only to find that my plugin isn’t yet compatible.
I have a weekly release cadence with releases on Thursday mornings (my time), so I’m specifically asking if it seems like 2025.2 GA might be released before this Thursday so I know whether or not to issue a release of my plugin with 2025.2 compatibility earlier this week.
Thanks in advance for any guidance you can provide.
That is very sad that your plugin is not available for RC I can only say.
Users again will tell us how they don’t want to upgrade their IDE because of missing plugins
That is very sad that your plugin is not available for RC I can only say.
Well, to provide some context, I’ve had a commercial plugin available for over a full decade now (since 2015 / IntelliJ IDEA 2015), and for a long time I didn’t even set until-build. I actually started setting until-build based on guidance from JetBrains because there were many, many times where changes to the plugin SDK – of which my plugin implements a very large set of EPs – would break functionality. There have even been a few rare times where a last minute change between RC and GA has resulted in a regression.
So while my approach may not seem ideal to you, it’s proven to be the right one for my customers who rely on my product for their day-to-day productivity, and that’s what’s important to me.
Having said that, do you have an answer to the question that I asked about the date/date range for GA of 2025.2?
I can only guess as it is released when fully tested and we rarely commit to a date
So while my approach may not seem ideal to you, it’s proven to be the right one for my customers who rely on my product for their day-to-day productivity, and that’s what’s important to me.
I would like to second this. Some of us are developing plugins which are users’ primary work tools. It seems infinitely preferable to me to have users sometimes wait a couple of days to upgrade their IDE over having their daily driver work tool break unexpectedly.
@lemming @illuminatedcloud, you are very active in our community; we appreciate that. Thank you so much for publishing at least builds for releases in time; this helps a lot.
The only problem with unavailable plugins for EAP is that we do not receive issues related to your users and cannot address them on time.
Cannot agree, the upgrade procedure is not unexpected and previous versions always available
Cannot agree, the upgrade procedure is not unexpected and previous versions always available
Well, yes and no. I certainly appreciate that you see it from one perspective, but please don’t ignore/dismiss our perspective on this, especially since it’s gained from years of staking our own careers on your platform.
Speaking only for myself, a significant proportion of my plugin’s users don’t come from a traditional development background. They’re not following JetBrains’ EAP program closely or even at all. While some users can patch to a newer version, they may have to get IT involved to downgrade to a previous version via an executable installer.
What I’ve seen more times than I can count is that the IDE shows a notification about a new version being available, the user clicks to upgrade, they may or may not be prompted that some plugins are not compatible with the newer version (at least at one point, they were definitely not prompted properly), and they proceed with the upgrade. Only after the IDE restarts do they learn that the plugin that they use as their primarily development tool no longer works, then have to figure out some way to get back into a working state. Again, many of these folks are not seasoned developers, so what is brain-dead simple for us can be a daunting task for them.
This is not hypothetical. This is exactly how things worked for several years until I started restricting my plugin to released, tested versions. That process change has required me to track the GA release of the next version closely so that I could have a tested, compatible version of my plugin ready for the next version in conjunction with its GA release, but that’s a small price to pay to avoid waking up to emails and bug reports from numerous users who found themselves in a bad state, even if it was (partially) their own fault (something I would never say to a paying customer even if true).
And to provide some perspective on the EAP/Beta/RC/GA process, looking at the change log for my plugin’s 2025.2 compatibility branch, I’ve had to make source-level changes to my plugin for roughly half of the EAP and Beta builds along the way, and that’s pretty much the norm. These are changes that would have broken some aspects of the functionality in a released build, at least for those using the 2025.2 EAP/Beta/RC. You can look at the issues I’ve logged in YouTrack for good examples of breaking plugin SDK changes that I’ve logged as I’ve participated in the EAP program over the years.
Yes, one option – and my guess is that it’s your preferred option – would be to have a dedicated distribution of my plugin for each IDE version and its corresponding SDK. And I did exactly that for the first several years given the vast plugin SDK differences between 15, 16, 17, and 18. But the overhead of building, testing, and just maintaining all of those branches was significant vs. being able to have a single distribution that maintains compatibility with one year’s worth of JetBrains IDE versions.
@lemming and I have been doing this for quite a long time now. We’re quite experienced – both with software development in general and with commercial JetBrains plugin development specifically – and we’ve both tried many, many plugin development and distribution models over the years to settle on those that work best for us, and more importantly, for our paying customers.
If those models are “very sad” to you, perhaps you might open a productive discussion with us about why we feel we need to do that and what JetBrains might be able to do to allow us to feel more confident about being able to support the next version of the underlying IDE instead of just summarily dismissing us as it feels you’re doing here.
2 Likes
To be clear, I also have an EAP process, so users are testing my upcoming releases early, and generally those same users are also using the JetBrains EAPs. JetBrains does receive errors from my plugin and occasionally contacts me about them. I do have dedicated distributions for multiple IntelliJ versions, which introduces a lot of overhead but is the only way I found to make this tractable. As Scott has observed, essentially every IntelliJ release requires some API changes for me, and that is functionality that would break if the version of my product was not tied to the version of the platform. When there’s a GA release of IntelliJ, if for whatever reason my plugin isn’t ready I usually get it ready within a couple of days - I think the longest I might have taken was a week. So it’s not like it’s holding users up from upgrading IntelliJ for significant amounts of time, but that crossover period is awkward for users who have to know that they shouldn’t upgrade yet. Knowing the release date ahead of time would help us plan for that event.
3 Likes
I’d also like to voice my support for @illuminatedcloud and @lemming.
On the old Slack development community, the expected release dates were mentioned at least a few times. This has been very helpful to schedule our own work and releases. If a IDE release is postponed or delayed, that’s understandable. But having no idea which week the releases are likely to land is making it difficult.
I’m publishing releases for each major version. In the past (a few years ago) I published without until-build and also attempted to provide a single build for multiple major versions, but none of this worked reliable enough for me and my users. Unless a plugin is very simple or only touches very old and stable API of the SDK, I publish one build per major version.
I don’t publish for a new major version before I haven’t seen at least an RC build of that new IDE release.
I try to prepare my builds after the first EAPs were made available. I’m doing that to be able to report unexpected changes to the API on YouTrack, even though these seem to be ignored at times ([example](https://youtrack.jetbrains.com/issue/IJPL-187891).
If users are telling JetBrains that they don’t upgrade due to missing plugins, but the developers of such plugins are concerned about release quality and would prepare builds if the release dates were known, perhaps JetBrains could consider to support such developers in a better way?
Thank you for your consideration!
2 Likes
I completely agree. Any kind of transparency or heads-up about the upcoming release is very helpful.
But why not start integration with RC versions? They exists exactly for that and we do not change anything major between them and releases, it is prohibited nowadays to fix anything, only critical patches are allowed between RC and the release.
In general, we try to harden all compatibility requirements recently, we hope stability of APIs improves, we do a lot to not break plugins