Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
SDK version mismatch
eckard_klotz:
Hello Everybody.
After installing the newest nightly from the 7th of November 2010 I tryed to install the plugins FileManager and PowerShell but since the versions currently available under the project-page Code::Blocks IL plugins (http://developer.berlios.de/projects/cbilplugin/) are from July 2009 I've got the following errors:
--- Quote ---SDK version mismatch for FileManager (1.11.12). Expecting 1.11.13
SDK version mismatch for PowerShell (1.11.12). Expecting 1.11.13
--- End quote ---
I posted a bug-description (#017702 SDK of Code::Blocks has changed again) I hope that the project of this 2 plugins is still alive and the new compiled versions will be load up soon. But I have some questions about this.
1. Why are this plugins no core-plugins (especially the file-manager)?
2. If the c::b core-project desides to use a new sdk-version is there a central announcement-place where this information for plugin-developers will be posted? (I know that the plugin-developers are responsible to hold their software up-to-date, but currently as user I wonder if it is my job to inform the plugin-project about changes.)
OK, please don't take me wrong if I choosed the wrong words I don't wont to be impolite. But since I think about write an own plugin for C::B for my doxygen helper-tool Moritz some when in the future it will be also importend for me to know about such things.
Best Regards,
Eckard Klotz.
killerbot:
You have a very good point, we should more clearly announce the SDK changes.
We will think about this :
* mainling list (for the plug-in developers ...)
* somewhere on the home page
Do note however : no plg-in is broken on the official version, only the nightlies. But since the nigthlies are very stable and widely used, we should do a better effort in supporting the plug-in developers.
As for the 2 mentioned plug-ins, I think they should become contrib plug-in, let's discuss this with th original author.
Good to hear you are going to write a plug-in. Did you check with our current doxygen plug-in ?
Maybe you can join forces with its author to improve on the existing one ... just an idea ;-)
Thanks for the feedback.
MortenMacFly:
--- Quote from: eckard_klotz on November 14, 2010, 10:05:11 am ---1. Why are this plugins no core-plugins (especially the file-manager)?
--- End quote ---
We had several attempts to transfer these into C::B's repo as core plugins, hence the current state is "they need some clean-up" to my knowledge. It's better to ask dmoore about this.
Biplab:
IMO, we should modify our sdk to allow any plugin compiled with a lower version sdk to be run. My idea is-
--- Code: ---SDK_Version = {Release}.{Major}.{Minor}
--- End code ---
E.g.,
Release|Value10.05|111.05|2
Similarly {Major} and {Minor} will be assigned depending on the maturity of the release.
Rules for {Major} value change -
a) Deletion of any sdk class / function.
b) Interface change (can be parameter type, function return type change)
Rules for {Minor} value change-
a) Addition of new class / function.
b) Interface change (can be parameter type, function return type change) but old interface is still intact.
Now when C::B sees any sdk version change-
a) If {Minor} has changed, load & run plugin without warning.
b) If {Major} has changed, load & run plugin with warning. Warning should inform users that the plugin could be unstable with new sdk version; so use it with a grain of salt.
c) If {Release} has changed, inform users to source for a newer version of that plugin.
My point is even a small change in sdk should not force a plugin to be recompiled, especially when the plugin under question is not affected by the change.
Anyway this is just a draft idea. Feel free to update/comment.
I'm also not in favour of the idea to add plugins to the repo to ensure that they stay updated when we change sdk version. We do have couple of almost unmaintained plugins and I don't want to see their numbers increase any further. We should add plugins to our repo only when someone is there to maintain it. :)
MortenMacFly:
--- Quote from: Biplab on November 16, 2010, 03:46:40 pm ---We do have couple of almost unmaintained plugins [...]
--- End quote ---
Which one are these?
BTW: My idea was to create a second repo / project just for the contrib plugins, where plugin authors have full access. This would no clutter the core, but still allow to have everything in one place, easy to be maintained. Becoming a member f this project would be as easy as to provide a working draft of a plugin (which then of course can be further developed). Then upon a release we can decide which contrib plugins are "mature enough" to make it into a distribution. Probably even through a poll in the forums.
Navigation
[0] Message Index
[#] Next page
Go to full version