Plugins, 4.0 and Pallada

4.0 has barely been released and we're already seeing
new or updated plugins that don't work with 4.0. They
work with "the EAP version", "pallada", "build 2008".

Plugins play a big role in how the core product is perceived
and accepted. IDEA's core is awesome and we have some
seriously good plugins, too. That makes a compelling package
for people to move to 4.0.

Now if plugin development focuses on pallada without being
compatible with 4.0 then I think we are not helping 4.0 get
accepted. Most people out there might buy or upgrade to
production 4.0 and very few them will know about EAP. Seeing
these great plugins that throw exceptions in their brand new
IDEA will be a tease and a big deception.

I think the plugin community should strive to create plugins
that work with 4.0 (the OpenAPI permitting) and maybe
maintain a version that also works with Pallada. And Dave
I'm not only saying that for MetricsReloaded :)

Just a few $0.01. What do you guys think?

Vince.


4 comments
Comment actions Permalink

The plugin API needs to have a way to precisely know on what versions
(build number!) a plugin is meant to be runned in.
And the plugin manager should only list plugins that it is sure will run
on the build currently running.

BoD

Vincent Mallet wrote:

4.0 has barely been released and we're already seeing
new or updated plugins that don't work with 4.0. They
work with "the EAP version", "pallada", "build 2008".

Plugins play a big role in how the core product is perceived
and accepted. IDEA's core is awesome and we have some
seriously good plugins, too. That makes a compelling package
for people to move to 4.0.

Now if plugin development focuses on pallada without being
compatible with 4.0 then I think we are not helping 4.0 get
accepted. Most people out there might buy or upgrade to
production 4.0 and very few them will know about EAP. Seeing
these great plugins that throw exceptions in their brand new
IDEA will be a tease and a big deception.

I think the plugin community should strive to create plugins
that work with 4.0 (the OpenAPI permitting) and maybe
maintain a version that also works with Pallada. And Dave
I'm not only saying that for MetricsReloaded :)

0
Comment actions Permalink

Hi,
For this purposes exists <idea-version min="4.1" max="4.1"/> or something like this, but it doesn't handled correctly as I'm see.
Develop plugin for 2 versions is very difficult especially if it use PSI or unopened officially classes.
Release of Pallada will be in approximate 2 month(hope so) and current versions very stable, many users use it for production.

TIA,
Dmitry

0
Comment actions Permalink

At last, if any new versions and not just major or eap versions (for ex. 4.0 -> pallada will be 4.1) requires rewriting part of plugin, then make no mistake : you could not safely rely on a regular update for these plugins, beacuse plugin's developper will have to do a lot of tests and work to get their plugins working on every version. Some will, some will not depending on their work schedule (the kind of work you'll get paid for).
And YES, you are right, this is a problem as when I see (in the forums) some key plugin not working in some version, that prevents us for upgrading to this version.

Richard

0
Comment actions Permalink


It's a nice idea, but probably not reasonable to expect. The combination of unstable and rapidly expanding API, expectation of a short release cycle for 4.1, and volunteer plugin writers eager to play with the newly opened API, are gonna make for a rocky few months. Maybe this problem simply needs a quick technical fix. I strongly feel that the Plugin Manager should take version tags into account in presenting plugins to users. MetricsReloaded is marked in it's plugin.xml as only working in 4.1, but it still only took a few hours before I got my first "hey, this doesn't work in Aurora" complaint.

--Dave Griffith

0

Please sign in to leave a comment.