We were told that using an Internal API was okay, then suddenly JetBrains has decided (on a Friday) that your (opensource, btw, with 12 years of history) plugin uses ApiStatus.NonExtendable, and they’ve deprecated your plugin, without warning, and it was the same person who you spoke to before about it – oh, and the fucking kicker? It’s still private.
So I have one person here telling me that it’s fine to use certain APIs, then another person telling me it’s fine, until it’s not. And without even a way forward.
JetBrains can’t even manage/scan their own plugins, WTF does the community have of these arbitrary rules.
We need to support multiple IDE versions.
I don’t understand how JetBrains just thinks we’re either:
Going to maintain multiple versions - which wouldn’t even work, AS THE APIS ARE STILL INTERNAL/NONEXTENDABLE.
Just tell users to upgrade/go fly a kite.
I spend more time actually battling with Jetbrains nonsense at this point than maintaining the plugin, honestly.
Hi, let’s make this discussion more constructive and get understanding what is going on and where.
First of all, we do not just introduce Internal API marks without a reason. Often it is caused by real security and safety threats. In order to not break plugins right away, we at the same time introduce limitations gradually. It means that verifications will fail, but we try to approve all existing usages till next Major release, so you may support some more Major versions.
ApiStatus.NonExtendable is a very strict thing, it means we do not agree that you pass to our APIs any your subclasses of that API. We do not support that contract, we did not agree to that, it is unsupported, will not work properly. Could you now bring a reference to this case so we may discuss it?
You’re right. I’m sorry, I apologise - I got a bit tired and grumpy and shouldn’t have posted what I did. Thank you for calling that out, and for turning the conversation back around.
It’s great that JB clearly delineates where its support begins and ends within the platform. But that’s all JB needs to do, let the plugin author decide whether using an internal API is worth owning the extra maintenance cost. Sometimes these APIs are the only recourse.
Otherwise, JB invites hacks that make matters worse, like using reflection and other strategies that bypass static analysis.
While I agree with you that it’s annoying and very unpleasant, at least they are still humans that may bend the rules if they admit they have no better solutions. In other places, like with Apple, Google, Mozilla, Meta or Microsoft, they can just simply remove your app, plugin or webpage without a warning, sometimes even a way to appeal, and good luck trying to talk to a human.
But yeah these rules are very impacting the productivity and hinders innovation, that’s for sure.
Honestly, if a plugin release is rejected because it’s using an internal API via reflection, I guess the “Hide Trial” plugin should be the first to be ejected
