Supporting multiple distinct major versions of a plugin
I'm planning to introduce the next major version (2.x) of my plugin very soon. For all intents and purposes it will be considered a distinct product from the previous major version (1.x), as it's going to be licensed and supported separately. I don't want users of 1.x to be prompted by the plugin repository when 2.x updates are released, only when 1.x updates are released. I will likely tell 1.x users when 2.x is available if they want to upgrade, but I don't want the lifecycle of the two major versions intertwined any more than that.
As far as I can tell, the only way to do this is to publish a completely new plugin on the plugin repository with its own ID. Because both major versions of the plugin will compete for the same filetypes and other extension points, I assume I need to help the user ensure that only one of the two plugins is enabled/installed at any given time.
Is this correct, or is there a more first-class way to handle major "lifecycle branches" with a single plugin?
Thanks in advance for any insights!
请先登录再写评论。
Yes, your approach is correct. To solve the problem of conflicting functionality of "1.x" and "2.x" plugins you can implement `PluginReplacement` extension point in new versions of your "1.x" plugin. Then IDE would suggest to disable "1.x" plugin if both are enabled.
Thanks, Ivan, for confirming, and for letting me know about that EP. Sounds like it should be pretty reasonable to address.
Hi Ivan, can that EP be used in either direction, i.e. can I override `getOldPluginDescriptor` and return a descriptor for another plugin? In my case my plugin completely replaces another, which has been deprecated but is still available in the plugin repo. I can't easily make another release of that plugin implementing this EP. It would be useful to be able to warn users that they're likely to see very confusing behaviour if they don't remove the other one (which sometimes happens).
Colin, I don't think so, though you might wait for Ivan to say for sure. That EP seems to be explicitly called when a new plugin is installed, and if the new plugin ID is the one referenced in the EP implementation, it's considered a replacing plugin and the current one is disabled.
Also, this EP alone didn't do it for me. Because it only kicks in when the replacing version is installed, you can still run into trouble if the user decides to enable both simultaneously at any other time. In particular there was an exception when the second plugin tried to register the same language with the IDE, and it ends up being an unrecoverable exception during IDE startup.
I've since instrumented a few key entry points--in particular access to the custom languages in my plugin--to check for both major versions being installed and enabled. If that state is detected, I prompt the user as to which one should be disabled, do that for them, and restart the IDE. At the point when this happens the IDE is in such a nascent state that I couldn't even use Messages to prompt the user, instead having to resort to good old JOptionPane.
It's working to my satisfaction now, but this EP alone didn't get me there.
Thanks Scott - looking at how IntelliJ uses the EP that was my suspicion. That sounds like a good approach. There are actually a couple of other plugins for the same language as mine which I'd like to detect as well. Which EPs did you do the detection in? I would have thought that just doing the detection in an ApplicationComponent would be sufficient - did you try this and encounter problems with it?
Colin, it turns out that in my case, all paths led to a very small set of places, in particular my custom language constructors which were referenced as singletons all over the place. I'd had those as singletons initialized at the point of declaration which caused the issue during classloading, so I just changed them to be lazy-initialized and checked for plugin conflicts before assigning creating the instance. If there are plugin conflicts, only one plugin is left enabled and the IDE is restarted. I'm happy to shoot you more implementation details if you'd like. Just shoot me an email.