Agree. But also "in which version did the functions parameters and/or semantics change" is more important. If that change is newer than the plugin then the plugin shouldn't try to run.
I think that a simple update of the API version for this function is good enough for this. And anyway, I think that the current API scheme of Geany doesn't allow such changes without a function rename, so it would probably never happen, would it?
Change of parameters probably should cause a rename, change of semantics (could be a bugfix) doesn't.
This would make
easier for plugin developers to know for which version check. Also, perhaps a compile-time check would be interesting, it would allow things like "if Geany version is too old for this, it's not fatal, we will do without" -- stop me if it already exists.
The plugin only depends on the ABI it wants to use, so in a perfect world it would be able to check the each function it wants to call for the version in which it last changed. This will allow plugins to continue to operate as long as possible without rebuilding.
At initialisation the plugin could simply present a list of functions and Geany could then return a list of versions for them (from a table extracted from the doc comments). It is then up to the plugin to avoid functions it can't use, eg by not running at all or by limiting functionality to avoid using functions that are too new, too old or don't exist.
I think this is probably overkill, and would make the plugin development really hard it it is a runtime check. Why? because you loose all the compile-time safety that tells us if we use an undefined symbol, if it isn't compatible and so on.
No, if you are compiling against an old Geany you can still remove the code that uses newer features using #ifdefs and the statically defined version of the ABI as you say below.
It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.
Recompiling is not (much of?) a pain for us developers, but it is a pain for other people who use Geany for non-C development. They might not even have a C development environment, especially on Windows. Using Geany or plugins should not be dependent on being able to build it.
The static version dependency means that either plugin development is stalled if it needs newer API, or older versions of Geany are not supported.
In fact even if no new features are used, a new geany_plugins release will no longer run with an old version.
To support older versions of Geany, plugin devs need to maintain multiple versions of their plugin and backport bugfixes, lotsa work and doesn't fit into geany_plugins combined releases. I'm not talking about very old versions of Geany, the problem happens immediately at release of a new version. Geany maintains compatibility with *ancient* versions of GTK, why then does it require itself to be the latest version?
I personally think that protecting code with something like #if GEANY_CHECK_API_VERSION(421) ... #endif is enough.
Yes if you are compiling.
Saying this makes me remember that Geany uses a macro for each function in the plugin API, so it is actually already possible to do a similar check: #ifdef a_geany_function ... #endif
Well... this gives lot of stuff to think about :D
Yes, isn't it past your bedtime again??
Cheers Lex
My 2 cents, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel