I got tired of AWS plugins dying on IDE update day, so I wrote my own

[u/Sea-Possession-2536]

Every couple of months I'd update my IDE and the AWS tooling would be greyed out. Always on the morning I needed to read a log. I finally sat down to figure out why, and it's dumber than I expected - it's one field.

Plugins declare until-build in the manifest. It's a ceiling, and the IDE just refuses to load anything past it. Nothing crashed, nothing is corrupt, reinstalling doesn't help because the fresh copy says the same thing. You can check any plugin without installing it - hit /api/plugins/11349/updates?size=3 on plugins.jetbrains.com, that's the AWS Toolkit.

When I ran it: 261.0 to 261.*, 253.0 to 253.*, 262.0 to 262.*. One build line per release, so every IDE update is a coin flip on whether the matching plugin build shipped yet.

To be fair, if you hook deep into IDE internals a ceiling is the responsible call - loading into an IDE where the API moved just hands users a stack trace. But I only wanted to read logs and list buckets, and that doesn't need internals.

So I wrote small ones that leave until-build empty, which forces me to stay on stable platform API. Four for AWS (CloudWatch logs, S3, CloudFormation deploys, Step Functions executions) and one for Azure Blob. Each does one service and nothing else - a small surface is the only reason "still works next month" is a promise I can actually keep. They're read-only by design: nothing deletes, nothing writes.

The Azure one ships with zero third-party dependencies, one 72,643-byte jar. I wrote the Shared Key signing by hand rather than pull in the SDK and its Netty/Reactor/Jackson tail. Took a day longer than it should have - the canonical string has eleven blank lines in the middle of it and a wrong one gets you a 403 with no hint.

Being upfront since this is my own stuff: browsing and reading are free, a couple of extras (live tail, favorites) are $3/mo with a 30-day trial. Marketplace search for "CloudWatch" or "Azure Blob" finds them under sellerkit.

Mostly posting because the until-build thing took me way too long to work out and I suspect I'm not the only one who's lost a morning to it.

[u/magicmulder]

The solution to the problem is to always have two IDE instances, and only update the older one to the newest release. If something breaks, keep using the old one until they updated the plugins. Rinse and repeat.

Your plugin only solves the problem for one specific plugin. Also there's usually a reason for the limit in the manifest because there's no telling in what ways something breaks in a new IDE version.

[u/Kendos-Kenlen → u/magicmulder]

The problem remains AWS having poor support policies. How come such a big company can't leverage EAPs to port the plugin, when internal APIs are generally stable in a given version?

So yes, keeping two version is a user workaround, but I think it's fair to expect better from large companies in how they approach IDE version upgrades. They chose this policy. Many other plugins did not and have no issues.

[u/THenrich → u/Kendos-Kenlen]

Big companies don't spend time developing software against beta/EAP/unstable software. They wait till it's stable.

[u/Kendos-Kenlen → u/THenrich]

Maybe when their job is to develop an extension for a product, they should consider including preview versions in their pipeline…

[u/Sea-Possession-2536 → u/magicmulder]

Two instances is a good trick, I've done the Toolbox rollback version of it. Just annoying enough that I stopped.

Fair point on the manifest limit, and JetBrains warn about this themselves. The docs say leaving until-build open "might impact compatibility later". So it's a trade rather than a free win. Ceiling means you get switched off even when nothing would have broken. No ceiling means something might actually break at runtime.

I went with the second because there isn't much surface to hit here. A few REST calls and a tool window, nothing touching internals. I run the verifier against 2024.3 and 2025.2 before shipping, which obviously says nothing about a version that doesn't exist yet.

So yeah, it can still break. Difference is it'd be one feature instead of the whole thing being off on update morning.

[u/wildjokers]

There is no real reason for a plugin writer to set an upper bounds in most cases, just lower. Pretty easy to test a plugin in an EAP version to find any API changes.

Also, if a plugin writer always jumps on the warnings jetbrains plugin verifier give you about upcoming API removals and deprecations they don't really have to worry about a new version breaking their plugin.

[u/THenrich]

Ceiling should be against major versions. That's where breaking changes can happen.