Let's start with the usual kudos for a great product and if my continuing participation and plugin development for your product is not stronger than my words I do not know how to tell you how I appreciate what you do to make our life easier.
However, and this is the start of my little rant... with the inexistence of proper documentation to support the openapi I believe you need to use standard mechanism to guide us plugin developer in upgrading to new revs.
Please maintain old api as much as you can and USE DEPRECATION! Several times in the past things could have been handled a lot smoother by just deprecating apis instead of changing them. You might need to build some backward compatible refactoring options (like http://www.intellij.net/tracker/idea/viewSCR?publicId=5195) but everybody would benefit.
813 is a great example:
1)fileStatusChanged renamed to refreshFileStatus.
(Note that I think the new name convey a lot better the intent of that method)
2) The new AbstractVcs api.
AbstractVcsCapabilities is no longer used. However it wasn't removed (oversight?). Now we get to implement a few XXXProvider instead of directly implementing the moveXXX and renameXXX methods in AbstractVcs.
The danger with this is (I fell for it in the ClearCasePlugin 1.20) the new API format doesn't help me detect the change. It silently go through compilation but the resulting behavior of the plugin is completely different. No more support for move/rename.
Think about your users. Make the old interface calls the new one or in this instance remove the Capabilities class and/or make the old moveXXX/renameXXX private.
Make your code self documented and backward compatible (or at least have fail-fast upgrade path to guide developer though the upgrade).
One of your biggest supporter.